Résultat inattendu du test de performances node.js vs ASP.NET Core

Question

Je suis en train de faire un rapide test de stress sur deux (un peu) bonjour tout le monde, des projets écrits en node.js et asp.net-core. Deux d'entre eux sont en cours d'exécution en mode de production et sans un enregistreur attaché à eux. Le résultat est bluffant! ASP.NET core est plus performant node.js application même après avoir fait du travail supplémentaire alors que le node.js app est juste le rendu de la vue.

Application 1: http://localhost:3000/nodejs node.js

À l'aide de: node.js, d'exprimer et de vash'moteur de rendu.

Le code de ce point de terminaison est

router.get('/', function(req, res, next) {
  var vm = {
    title: 'Express',
    time: new Date()
  }
  res.render('index', vm);
});

Comme vous pouvez le voir, il ne fait rien en dehors de l'envoi date actuelle via l' time variable pour l'afficher.

Application 2: http://localhost:5000/aspnet-core asp.net core

À l'aide de: ASP.NET de Base, le modèle par défaut de ciblage dnxcore50

Cependant, cette application n'est autre chose que simplement le rendu d'une page avec une date. Il génère 5 paragraphes de divers textes aléatoires. Cela devrait théoriquement faire ce petit peu plus lourd que l'application nodejs.

Voici la méthode d'action qui rendent cette page

[ResponseCache(Location = ResponseCacheLocation.None, NoStore = true)]
[Route("aspnet-core")]
public IActionResult Index()
{
    var sb = new StringBuilder(1024);
    GenerateParagraphs(5, sb);

    ViewData["Message"] = sb.ToString();
    return View();
}

Résultat de test de Stress

Node.js Application de test de stress suite

Mise à jour: Suite à la suggestion de Gorgi Kosev

À l'aide de npm install -g recluster-cli && NODE_ENV=production recluster-cli app.js 8

ASP.NET Core App test de stress suite

Ne peux pas en croire mes yeux! Il ne peut pas être vrai que dans ce test de base asp.net de base est de manière plus rapide que nodejs. Bien sûr ce n'est pas le seul paramètre utilisé pour mesurer la performance entre ces deux technologies web, mais je me demande ce que je fais mal dans le node.js côté?.

Être un professionnel de la asp.net développeur et qui veulent s'adapter node.js dans les projets personnels, c'est gentil de me mettre hors - comme je suis un peu paranoïaque à propos de la performance. J'ai pensé node.js est plus rapide que asp.net de base (en général - comme on le voit dans les divers autres points de référence), je veux juste prouver à moi-même (pour m'encourager, dans l'adaptation de node.js).

Merci de répondre en commentaire si vous voulez me comprennent plus les extraits de code.

Mise à jour: La distribution du temps de .NET de Base app

Réponse du serveur

HTTP/1.1 200 OK
Cache-Control: no-store,no-cache
Date: Fri, 12 May 2017 07:46:56 GMT
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
Server: Kestrel

Answer 1

Comme beaucoup d'autres ont fait allusion, la comparaison manque de contexte.
Au moment de sa sortie, la async approche de node.js était révolutionnaire. Depuis, d'autres langages et frameworks web ont adopté des approches qu'ils ont pris grand public.

Pour comprendre ce qu'est la différence signifie, vous avez besoin de simuler une demande de blocage qui représente les IO de la charge de travail, comme une demande de base de données. Dans un fil par système de demande, ce sera d'échappement le pool de threads et de nouvelles demandes seront mis dans une file d'attente d'un thread.
Avec les non-blocage-io cadres, cela n'arrive pas.

Considérez ceci node.js serveur qui attend 1 seconde avant de répondre

const server = http.createServer((req, res) => {
  setTimeout(() => {
    res.statusCode = 200;
    res.end();
  }, 1000);
});

Maintenant, nous allons jeter 100 simultanées conenctions à elle, pendant 10s. Donc, nous nous attendons à environ 1000 requêtes.

$ wrk -t100 -c100 -d10s http://localhost:8000
Running 10s test @ http://localhost:8000
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.01s    10.14ms   1.16s    99.57%
    Req/Sec     0.13      0.34     1.00     86.77%
  922 requests in 10.09s, 89.14KB read
Requests/sec:     91.34
Transfer/sec:      8.83KB

Comme vous pouvez le voir, nous recevons dans le stade de baseball avec 922 terminé.

Considérons maintenant la suite asp.net code, écrit comme si async/await n'étaient pas encore pris en charge, donc la datation de nous ramener à l'node.js lancement de l'époque.

app.Run((context) =>
{
    Thread.Sleep(1000);
    context.Response.StatusCode = 200;
    return Task.CompletedTask;
});

$ wrk -t100 -c100 -d10s http://localhost:5000
Running 10s test @ http://localhost:5000
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.08s    74.62ms   1.15s   100.00%
    Req/Sec     0.00      0.00     0.00    100.00%
  62 requests in 10.07s, 5.57KB read
  Socket errors: connect 0, read 0, write 0, timeout 54
Requests/sec:      6.16
Transfer/sec:     566.51B

62! Ici, nous voyons la limite du pool de threads. Le réglage par elle, nous aurions pu faire plus de demandes simultanées qui se passe, mais au prix de plus de ressources du serveur.

Pour ces IO-tenu des charges de travail, le déplacement afin d'éviter de bloquer les threads de traitement a été spectaculaire.

Maintenant, nous allons l'amener à aujourd'hui, où que l'influence s'est propagée à travers l'industrie et de permettre dotnet pour profiter de ses améliorations.

app.Run(async (context) =>
{
    await Task.Delay(1000);
    context.Response.StatusCode = 200;
});

$ wrk -t100 -c100 -d10s http://localhost:5000
Running 10s test @ http://localhost:5000
  100 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.01s    19.84ms   1.16s    98.26%
    Req/Sec     0.12      0.32     1.00     88.06%
  921 requests in 10.09s, 82.75KB read
Requests/sec:     91.28
Transfer/sec:      8.20KB

Pas de surprises ici, nous avons maintenant le match node.js.

Alors, que veut dire tout cela?

Vos impressions node.js est le "plus rapide" viennent d'une époque que nous ne vivons plus dans. Ajoutez à cela qu'il n'a jamais été node/js/v8 qui ont été "rapide", c'est qu'ils ont cassé le fil par-modèle de requête. Tout le monde a été rattrapage.

Si votre objectif est le traitement plus rapide des demandes isolées, puis regarder le sérieux des repères au lieu de rouler votre propre. Mais si au lieu de ce que vous voulez, c'est simplement quelque chose qui s'adapte à des normes modernes, puis aller pour la langue que vous aimez et assurez-vous que vous n'êtes pas le blocage de ces threads.

Avertissement: Tout le code écrit, et de l'exécution des tests, sur le vieillissement de MacBook Air lors d'une somnolence dimanche matin. Hésitez pas à saisir le code et de l'essayer sur Windows ou le personnaliser à vos besoins https://github.com/csainty/nodejs-vs-aspnetcore

Answer 2

Nœud de Cadres comme l'Express et Koa ont un terrible frais généraux. "Raw" Nœud est nettement plus rapide.

Je n'ai pas essayé, mais il y a un nouveau cadre qui devient très proche de "Raw" de la performance des nœuds: https://github.com/aerojs/aero

(voir la référence de la page)

mise à jour: Voici quelques chiffres: https://github.com/blitzprog/webserver-benchmarks

Node:
    31336.78
    31940.29
Aero:
    29922.20
    27738.14
Restify:
    19403.99
    19744.61
Express:
    19020.79
    18937.67
Koa:
    16182.02
    16631.97
Koala:
    5806.04
    6111.47
Hapi:
    497.56
    500.00

Comme vous pouvez le voir, les frais généraux les plus populaires node.js les cadres sont TRÈS importants!