Node.js vs .Net rendimiento

He leído mucho acerca de que Node.js es rápido y capaz de acomodar grandes cantidades de carga. ¿Alguien tiene alguna evidencia del mundo real de este vs otros marcos, particularmente .Net? La mayoría de los artículos que he leído son anecdóticos o no tienen comparaciones con .Net.

Gracias

Ser RÁPIDO y manejar mucha CARGA son dos cosas diferentes. Un servidor que es realmente RÁPIDO para atender una solicitud por segundo podría ser totalmente malicioso si le envía 500 solicitudes por segundo (bajo CARGAR ).

También debe considerar las páginas estáticas (y en caché) frente a las dinámicas. Si le preocupan las páginas estáticas, entonces IIS probablemente va a vencer al nodo porque IIS usa el almacenamiento en caché en modo kernel, lo que significa que las solicitudes que solicitan una página estática ni siquiera saldrán del kernel.

Supongo que está buscando una comparación entre ASP.NET y el nodo. En esta batalla, después de que todo haya sido compilado / interpretado, es probable que tengas un rendimiento bastante cercano. Tal vez .NET sea un poco más RÁPIDO o tal vez el nodo sea un poco MÁS RÁPIDO , pero probablemente esté lo suficientemente cerca como para que no te importe. Apostaría en .NET, pero no estoy seguro.

El lugar en el que ese nodo es realmente convincente es para manejar LOAD . Aquí es donde las tecnologías realmente difieren. ASP.NET dedica un subproceso para cada solicitud de su grupo de subprocesos, y una vez que ASP.NET se ha agotado, todas las solicitudes de subprocesos disponibles comienzan a ponerse en cola. Si está sirviendo aplicaciones "Hello World" como el ejemplo de @shankar, entonces esto podría no importar mucho porque los hilos no serán bloqueados y podrá manejar muchas solicitudes antes que usted quedarse sin hilos. El problema con el modelo ASP.NET se produce cuando comienza a realizar solicitudes de E / S que bloquean el hilo (llamar a una base de datos, realizar una solicitud http a un servicio, leer un archivo del disco). Estas solicitudes de bloqueo significan que su valioso hilo del grupo de hilos no está haciendo nada. Cuanto más bloqueo tengas,CARGUE su aplicación ASP.NET podrá servir.

Para evitar este bloqueo, utiliza puertos de finalización de E / S que no requieren mantener un hilo mientras espera una respuesta. ASP.NET admite esto, pero desafortunadamente muchos de los frameworks / bibliotecas comunes en .NET NO. Por ejemplo, ADO.NET admite puertos de finalización de E / S, pero Entity Framework no los usa. Por lo tanto, puede crear una aplicación ASP.NET que sea puramente asíncrona y maneje mucha carga, pero la mayoría de las personas no lo hacen porque no es tan fácil como construir una que sea síncrona, y es posible que no pueda usar algunas de sus partes favoritas del marco (como linq a entidades) si lo hace.

El problema es que ASP.NET (y .NET Framework) se crearon para no tener opiniones sobre las E / S asíncronas. A .NET no le importa si escribe código síncrono o asíncrono, por lo que depende del desarrollador tomar esta decisión. Parte de esto se debe a que el enhebrado y la programación con operaciones asincrónicas se consideraba "difícil", y .NET quería hacer felices a todos (novatos y expertos). Se puso aún más difícil porque .NET terminó con 3-4 patrones diferentes para hacer asíncrono. .NET 4.5 está tratando de retroceder y adaptar el .NET Framework para tener un modelo obstinado alrededor de IO asíncrono, pero puede pasar un tiempo hasta que los marcos que le interesan realmente lo admitan.

Los diseñadores de nodos, por otro lado, tomaron una decisión obvia de que TODAS las E / S deberían ser asíncronas. Debido a esta decisión, los diseñadores de nodos también pudieron tomar la decisión de que cada instancia del nodo sería de un solo subproceso para minimizar el cambio de subproceso, y que un subproceso simplemente ejecutaría el código que se había puesto en cola. Esa podría ser una nueva solicitud, podría ser la devolución de llamada de una solicitud de base de datos, podría ser la devolución de llamada de una solicitud de reposo http que realizó. Node intenta maximizar la eficiencia de la CPU eliminando los cambios de contexto de subproceso. Debido a que el nodo tomó esta decisión obvia de que TODAS las E / S son asíncronas, eso también significa que todos sus marcos / complementos admiten esta opción. Es más fácil escribir aplicaciones que son 100% asíncronas en el nodo (porque el nodo lo obliga a escribir aplicaciones que son asíncronas).

Nuevamente, no tengo ningún número difícil para probar de una forma u otra, pero creo que el nodo ganaría la competencia LOAD para la aplicación web típica. Una aplicación .NET altamente optimizada (100% asíncrona) podría ejecutar la aplicación node.js equivalente por su dinero, pero si toma un promedio de todas las aplicaciones .NET y todas las aplicaciones de nodo, en promedio, el nodo probablemente maneja más CARGA.

Espero que ayude.

Hice una prueba de rendimiento rudimentaria entre nodejs e IIS. IIS es aproximadamente 2,5 veces más rápido que nodejs cuando se distribuye "¡hola, mundo!". código a continuación.

mi hardware: Dell Latitude E6510, Core i5 (doble núcleo), 8 GB de RAM, sistema operativo Windows 7 Enterprise de 64 bits

servidor de nodo

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>

mi propio programa de referencia utilizando la biblioteca paralela de tareas:

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);
        }
    }

}
}

y resultados:

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

conclusión: IIS es más rápido que nodejs en aproximadamente 2.5 veces (en Windows). Esta es una prueba muy rudimentaria, y de ninguna manera concluyente. Pero creo que este es un buen punto de partida. Nodejs es probablemente más rápido en otros servidores web, en otras plataformas, pero en Windows IIS es el ganador. Los desarrolladores que deseen convertir su MVC de ASP.NET a nodejs deberían detenerse y pensar dos veces antes de continuar.

Actualizado (17/05/2012) Tomcat (en Windows) parece vencer a IIS, aproximadamente 3 veces más rápido que IIS al distribuir html estático.

gato

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

resultados de 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

Conclusión actualizada: ejecuté el programa de referencia varias veces. Tomcat parece ser el servidor más rápido en distribuir HTML ESTÁTICO EN VENTANAS.

Actualizado (18/05/2012) Anteriormente tenía 100,000 solicitudes totales con 10,000 solicitudes concurrentes. Lo aumenté a 1,000,000 de solicitudes totales y 100,000 solicitudes concurrentes. IIS sale como el ganador a gritos, con Nodejs cazando lo peor. He tabulado los resultados a continuación:

.

Los servidores NIO (Node.js, etc.) tienden a ser más rápidos que los servidores BIO. (IIS, etc.) Para respaldar mi reclamo, TechEmpower es una compañía especializada en puntos de referencia de framework web . Son muy abiertos y tienen una forma estándar de probar todos los framewrks.

Las pruebas de la ronda 9 son actualmente las últimas (mayo de 2014). Hay muchos sabores de IIS probados, pero la aspirina despojada parece ser la variante de IIS más rápida.

Aquí están los resultados en respuestas por segundo (más alto es mejor):

• Serialización JSON
  • nodejs: 228,887
  • despojado de aspnet: 105,272
• Consulta única
  • nodejs-mysql: 88,597
  • aspnet-stripped-raw: 47,066
• Múltiples consultas
  • nodejs-mysql: 8,878
  • aspnet-stripped-raw: 3,915
• Texto sin formato
  • nodejs: 289,578
  • despojado de aspnet: 109,136

En todos los casos, Node.js tiende a ser 2 veces más rápido que IIS.

Tengo que estar de acuerdo con Marcus Granstrom, el escenario es muy importante aquí.

Para ser sincero, parece que está tomando una decisión arquitectónica de alto impacto. Mi consejo sería aislar las áreas de preocupación y hacer un "horneado" entre las pilas que esté considerando.

Al final del día, usted es responsable de la decisión y no creo que la excusa "Un tipo en Stackoverflow me mostró un artículo que decía que estaría bien".

La principal diferencia que veo es que el nodo .js es un lenguaje de programación dinámico (verificación de tipo), por lo que los tipos deben derivarse en tiempo de ejecución. Los lenguajes fuertemente tipados como C # .NET teóricamente tienen mucho más potencial gana la lucha contra el Nodo .js (y PHP, etc.), especialmente cuando es un cálculo costoso. Por cierto, .NET debería tener una mejor interoperación nativa con C / C ++ que el nodo .js.