Como muchos otros han aludido, la comparación carece de contexto.
En el momento de su lanzamiento, el enfoque asincrónico de node.js fue revolucionario. Desde entonces, otros lenguajes y marcos web han estado adoptando los enfoques que se generalizaron.

Para entender lo que significaba la diferencia, debe simular una solicitud de bloqueo que represente alguna carga de trabajo de E / s, como una solicitud de base de datos. En un sistema de subproceso por solicitud, esto agotará el threadpool y se pondrán nuevas solicitudes en una cola esperando un hilo disponible.
Con marcos de e / s sin bloqueo, esto no sucede.

Considere este nodo.servidor js que espera 1 segundo antes de responder

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

Ahora vamos a lanzar 100 conexiones simultáneas, para 10s. Así que esperamos que se completen alrededor de 1000 solicitudes.

$ 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

Como pueden ver, llegamos al estadio con 922 completados.

Ahora considere lo siguiente asp.net código, escrito como si async / await no estuviera soportado todavía, por lo tanto saliendo con nosotros hasta el nodo.era de lanzamiento de js.

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! Aquí vemos el límite de la threadpool. Al ajustarlo, podríamos obtener más solicitudes simultáneas, pero a costa de más recursos del servidor.

Para estas cargas de trabajo vinculadas a IO, el movimiento para evitar bloquear los subprocesos de procesamiento fue tan dramático.

Ahora vamos a llevarlo a la actualidad, donde esa influencia se ha ondulado a través de la industria y permitir dotnet para aprovechar sus mejoras.

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

No sorpresas aquí, ahora coincidimos nodo.js.

Entonces, ¿qué significa todo esto?

Tus impresiones de ese nodo.js es el" más rápido " que viene de una época en la que ya no vivimos. Añadir a que nunca fue node / js / v8 que fueron "rápidos", fue que rompieron el modelo de hilo por solicitud. Todos los demás se han puesto al día.

Si su objetivo es el procesamiento más rápido posible de solicitudes individuales, entonces mire los puntos de referencia serios en lugar de rodar los suyos propios. Pero si en cambio lo que quieres es simplemente algo que escala a los estándares modernos, luego elige el idioma que te guste y asegúrate de no bloquear esos hilos.

Descargo de responsabilidad: Todo el código escrito, y las pruebas se ejecutan, en un MacBook Air envejecido durante una mañana de domingo soñoliento. Siéntase libre de agarrar el código y probarlo en Windows o ajustar a sus necesidades - https://github.com/csainty/nodejs-vs-aspnetcore