Node.js vs performances .Net

J'ai beaucoup lu sur Node.js étant rapide et capable de supporter de grandes quantités de charge. Quelqu'un a-t-il des preuves concrètes de cela par rapport à d'autres frameworks, en particulier .Net? La plupart des articles que j'ai lus sont anecdotiques ou n'ont pas de comparaison avec .Net.

Merci

Être RAPIDE et gérer beaucoup de CHARGE sont deux choses différentes. Un serveur qui répond vraiment RAPIDEMENT à une requête par seconde peut totalement croasser si vous lui envoyez 500 requêtes par seconde (sous CHARGE ).

Vous devez également considérer les pages statiques (et mises en cache) par rapport aux pages dynamiques. Si vous êtes préoccupé par les pages statiques, alors IIS va probablement battre le nœud car IIS utilise la mise en cache en mode noyau, ce qui signifie que les requêtes qui demandent une page statique ne sortiront même pas du noyau.

Je suppose que vous recherchez une comparaison entre ASP.NET et node. Dans cette bataille, une fois que tout a été compilé / interprété, vous serez probablement assez proche des performances. Peut-être que .NET est un peu plus rapide ou peut-être que le nœud est un peu plus rapide , mais il est probablement suffisamment proche pour que vous ne vous en souciez pas. Je parierais sur .NET, mais je ne sais pas avec certitude.

L'endroit où ce nœud est vraiment convaincant est la gestion de LOAD que votre application ASP.NET va pouvoir servir. LOAD . C'est là que les technologies diffèrent vraiment. ASP.NET dédie un thread pour chaque demande de son pool de threads, et une fois qu'ASP.NET a épuisé toutes les demandes de threads disponibles commencent à être mises en file d'attente. Si vous diffusez des applications "Hello World" comme l'exemple de @shankar, cela n'a peut-être pas d'importance car les fils ne seront pas bloqués et vous serez en mesure de traiter un grand nombre de demandes avant vous manquer de threads. Le problème avec le modèle ASP.NET survient lorsque vous commencez à faire des demandes d'E / S qui bloquent le thread (appel à une base de données, faire une demande http à un service, lire un fichier à partir du disque). Ces demandes de blocage signifient que votre précieux thread du pool de threads ne fait rien. Plus vous avez de blocage,

Pour éviter ce blocage, vous utilisez des ports d'achèvement d'E / S qui ne nécessitent pas de maintenir un thread pendant que vous attendez une réponse. ASP.NET prend en charge cela, mais malheureusement, de nombreux frameworks / bibliothèques courants dans .NET NE SONT PAS. Par exemple, ADO.NET prend en charge les ports d'achèvement d'E / S, mais Entity Framework ne les utilise pas. Vous pouvez donc créer une application ASP.NET qui est purement asynchrone et gère beaucoup de charge, mais la plupart des gens ne le font pas, car ce n'est pas aussi facile que de créer une application synchrone, et vous ne pourrez peut-être pas utiliser certaines de vos parties préférées. du framework (comme linq aux entités) si vous le faites.

Le problème est que ASP.NET (et le .NET Framework) ont été créés pour ne pas se prononcer sur les E / S asynchrones. .NET ne se soucie pas si vous écrivez du code synchrone ou asynchrone, c'est donc au développeur de prendre cette décision. Cela s'explique en partie par le fait que le threading et la programmation avec des opérations asynchrones étaient considérés comme «difficiles», et .NET voulait rendre tout le monde heureux (noobs et experts). Cela est devenu encore plus difficile car .NET s'est retrouvé avec 3-4 modèles différents pour faire l'asynchrone. .NET 4.5 essaie de revenir en arrière et de moderniser le framework .NET pour avoir un modèle d'opinion autour des E / S asynchrones, mais cela peut prendre un certain temps avant que les frameworks qui vous intéressent le prennent réellement en charge.

Les concepteurs du nœud, quant à eux, ont fait un choix avisé selon lequel TOUTES les E / S devraient être asynchrones. En raison de cette décision, les concepteurs de nœuds ont également pu prendre la décision que chaque instance de nœud serait un thread unique pour minimiser le changement de thread, et qu'un thread exécuterait simplement le code qui avait été mis en file d'attente. Cela peut être une nouvelle requête, ce peut être le rappel d'une requête DB, cela peut être le rappel d'une requête de repos http que vous avez effectuée. Node essaie de maximiser l'efficacité du processeur en éliminant les changements de contexte de thread. Parce que node a fait ce choix avisé que TOUTES les E / S sont asynchrones, cela signifie également que tous ses frameworks / modules complémentaires prennent en charge ce choix. Il est plus facile d'écrire des applications qui sont 100% asynchrones dans le nœud (car le nœud vous oblige à écrire des applications asynchrones).

Encore une fois, je n'ai pas de chiffres précis pour prouver d'une manière ou d'une autre, mais je pense que node gagnerait le concours LOAD pour l'application Web typique. Une application .NET hautement optimisée (100% asynchrone) peut donner à l'application node.js équivalente une course pour son argent, mais si vous prenez une moyenne de tous les .NET et de toutes les applications de nœuds, en moyenne, le nœud gère probablement plus CHARGE.

J'espère que cela pourra aider.

J'ai fait un test de performance rudimentaire entre nodejs et IIS. IIS est environ 2,5 fois plus rapide que nodejs lors de la distribution de "hello, world!". code ci-dessous.

mon matériel: Dell Latitude E6510, Core i5 (double cœur), 8 Go de RAM, système d'exploitation Windows 7 Entreprise 64 bits

serveur de nœuds

runs at http://localhost:9090/
/// <reference path="node-vsdoc.js" />
var http = require("http");
http.createServer(function (request, response) {
response.writeHead(200, { "Content-Type": "text/html" });
response.write("<p>hello, world!</p>");
response.end();
}).listen(9090);

default.htm

hosted by iis at http://localhost/test/
<p>hello, world!</p>

mon propre programme de référence utilisant la bibliothèque parallèle de tâches:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Net;
using System.Threading;
using System.Threading.Tasks;
using System.Diagnostics;

namespace HttpBench
{
class Program
{
    private int TotalCount = 100000;
    private int ConcurrentThreads = 1000;
    private int failedCount;
    private int totalBytes;
    private int totalTime;
    private int completedCount;
    private static object lockObj = new object();

    /// <summary>
    /// main entry point
    /// </summary>
    static void Main(string[] args)
    {
        Program p = new Program();
        p.Run(args);
    }

    /// <summary>
    /// actual execution
    /// </summary>
    private void Run(string[] args)
    {
        // check command line
        if (args.Length == 0)
        {
            this.PrintUsage();
            return;
        }
        if (args[0] == "/?" || args[0] == "/h")
        {
            this.PrintUsage();
            return;
        }

        // use parallel library, download data
        ParallelOptions options = new ParallelOptions();
        options.MaxDegreeOfParallelism = this.ConcurrentThreads;
        int start = Environment.TickCount;
        Parallel.For(0, this.TotalCount, options, i =>
            {
                this.DownloadUrl(i, args[0]);
            }
        );
        int end = Environment.TickCount;

        // print results
        this.Print("Total requests sent: {0}", true, this.TotalCount);
        this.Print("Concurrent threads: {0}", true, this.ConcurrentThreads);
        this.Print("Total completed requests: {0}", true, this.completedCount);
        this.Print("Failed requests: {0}", true, this.failedCount);
        this.Print("Sum total of thread times (seconds): {0}", true, this.totalTime / 1000);
        this.Print("Total time taken by this program (seconds): {0}", true, (end - start) / 1000);
        this.Print("Total bytes: {0}", true, this.totalBytes);
    }

    /// <summary>
    /// download data from the given url
    /// </summary>
    private void DownloadUrl(int index, string url)
    {
        using (WebClient client = new WebClient())
        {
            try
            {
                int start = Environment.TickCount;
                byte[] data = client.DownloadData(url);
                int end = Environment.TickCount;
                lock (lockObj)
                {
                    this.totalTime = this.totalTime + (end - start);
                    if (data != null)
                    {
                        this.totalBytes = this.totalBytes + data.Length;
                    }
                }
            }
            catch
            {
                lock (lockObj) { this.failedCount++; }
            }
            lock (lockObj)
            {
                this.completedCount++;
                if (this.completedCount % 10000 == 0)
                {
                    this.Print("Completed {0} requests.", true, this.completedCount);
                }
            }
        }
    }

    /// <summary>
    /// print usage of this program
    /// </summary>
    private void PrintUsage()
    {
        this.Print("usage: httpbench [options] <url>");
    }

    /// <summary>
    /// print exception message to console
    /// </summary>
    private void PrintError(string msg, Exception ex = null, params object[] args)
    {
        StringBuilder sb = new System.Text.StringBuilder();
        sb.Append("Error: ");
        sb.AppendFormat(msg, args);
        if (ex != null)
        {
            sb.Append("Exception: ");
            sb.Append(ex.Message);
        }
        this.Print(sb.ToString());
    }

    /// <summary>
    /// print to console
    /// </summary>
    private void Print(string msg, bool isLine = true, params object[] args)
    {
        if (isLine)
        {
            Console.WriteLine(msg, args);
        }
        else
        {
            Console.Write(msg, args);
        }
    }

}
}

et résultats:

IIS: httpbench.exe http://localhost/test

Completed 10000 requests.
Completed 20000 requests.
Completed 30000 requests.
Completed 40000 requests.
Completed 50000 requests.
Completed 60000 requests.
Completed 70000 requests.
Completed 80000 requests.
Completed 90000 requests.
Completed 100000 requests.
Total requests sent: 100000
Concurrent threads: 1000
Total completed requests: 100000
Failed requests: 0
Sum total of thread times (seconds): 97
Total time taken by this program (seconds): 16
Total bytes: 2000000

nodejs: httpbench.exe http://localhost:9090/

Completed 10000 requests.
Completed 20000 requests.
Completed 30000 requests.
Completed 40000 requests.
Completed 50000 requests.
Completed 60000 requests.
Completed 70000 requests.
Completed 80000 requests.
Completed 90000 requests.
Completed 100000 requests.
Total requests sent: 100000
Concurrent threads: 1000
Total completed requests: 100000
Failed requests: 0
Sum total of thread times (seconds): 234
Total time taken by this program (seconds): 27
Total bytes: 2000000

conclusion: IIS est plus rapide que nodejs d'environ 2,5 fois (sous Windows). C'est un test très rudimentaire, et en aucun cas concluant. Mais je pense que c'est un bon point de départ. Nodejs est probablement plus rapide sur d'autres serveurs Web, sur d'autres plates-formes, mais sur Windows, IIS est le gagnant. Les développeurs souhaitant convertir leur ASP.NET MVC en nodejs doivent faire une pause et réfléchir à deux fois avant de continuer.

Mise à jour (17/05/2012) Tomcat (sur Windows) semble battre IIS haut la main, environ 3 fois plus rapide que IIS pour fournir du HTML statique.

matou

index.html at http://localhost:8080/test/
<p>hello, world!</p>

résultats tomcat

httpbench.exe http://localhost:8080/test/
Completed 10000 requests.
Completed 20000 requests.
Completed 30000 requests.
Completed 40000 requests.
Completed 50000 requests.
Completed 60000 requests.
Completed 70000 requests.
Completed 80000 requests.
Completed 90000 requests.
Completed 100000 requests.
Total requests sent: 100000
Concurrent threads: 1000
Total completed requests: 100000
Failed requests: 0
Sum total of thread times (seconds): 31
Total time taken by this program (seconds): 5
Total bytes: 2000000

conclusion mise à jour: j'ai exécuté le programme de référence plusieurs fois. Tomcat semble être le serveur le plus rapide dans la distribution de HTML STATIQUE, SOUS WINDOWS.

Mise à jour (18/05/2012) Auparavant, j'avais 100 000 demandes au total avec 10 000 demandes simultanées. Je l'ai augmenté à 1 000 000 demandes totales et 100 000 demandes simultanées. IIS sort comme le vainqueur criant, avec Nodejs carénant le pire. J'ai tabularisé les résultats ci-dessous:

.

Les serveurs NIO (Node.js, etc.) ont tendance à être plus rapides que les serveurs BIO. (IIS, etc.). Pour étayer ma réclamation, TechEmpower est une société spécialisée dans les benchmarks de framework web . Ils sont très ouverts et ont une manière standard de tester tous les cadres.

Les tests du Round 9 sont actuellement les plus récents (mai 2014). Il existe de nombreuses versions IIS testées, mais aspnet-stripped semble être la variante IIS la plus rapide.

Voici les résultats en réponses par seconde (plus élevé est meilleur):

• Sérialisation JSON
  • nodejs: 228,887
  • aspnet-dépouillé: 105,272
• Requête unique
  • nodejs-mysql: 88,597
  • aspnet-stripped-raw: 47,066
• Requêtes multiples
  • nodejs-mysql: 8,878
  • aspnet-stripped-raw: 3,915
• Texte brut
  • nodejs: 289,578
  • aspnet-dépouillé: 109,136

Dans tous les cas, Node.js a tendance à être 2x + plus rapide que IIS.

Je suis d'accord avec Marcus Granstrom, le scénario est très important ici.

Pour être honnête, il semble que vous preniez une décision architecturale à fort impact. Mon conseil serait d'isoler les zones de préoccupation et de faire un «bake off» entre les piles que vous envisagez.

À la fin de la journée, vous êtes responsable de la décision et je ne pense pas que l'excuse "Un gars sur Stackoverflow m'a montré un article qui disait que tout irait bien" va le couper avec votre patron.

La principale différence, ce que je vois, c'est que node .js est un langage de programmation dynamique (vérification de type), donc les types doivent être dérivés au moment de l'exécution. Les langages fortement typés comme C # .NET ont théoriquement beaucoup plus de potentiel pour gagner la bataille contre Node .js (et PHP etc.), surtout là où le calcul est coûteux. Au fait, le .NET devrait avoir une meilleure interopérabilité native avec C / C ++ que le nœud .js.