正如许多其他人所暗示的那样，这种比较缺乏背景。
在其发布时，node.js的异步方法是革命性的。从那时起，其他语言和Web框架已经采用了它们的主流方法。
要理解这种差异的含义，您需要模拟一个表示某些IO工作负载的阻塞请求，例如数据库请求。在每请求一个线程的系统中，这将耗尽线程池，新的请求将被放入等待可用线程的队列中。
对于非阻塞IO框架，这不会发生。
假设这个node.js服务器在响应前等待1秒

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

现在让我们把100个并发连接放在它上面，10秒。我们预计将完成约1000个请求。

$ 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

正如你所看到的，我们在球场上完成了922。
现在考虑下面的asp.net代码，编写时似乎还不支持async/await，因此可以追溯到node.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！这里我们看到了线程池的极限。通过调整它，我们可以获得更多的并发请求，但代价是更多的服务器资源。
对于这些受IO限制的工作负载，避免阻塞处理线程的举措非常引人注目。
现在，让我们把它带到今天，在那里，这种影响力已经波及整个行业，并允许dotnet利用其改进。

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

毫无意外，我们现在匹配node.js。
那么这一切意味着什么呢？
你认为node.js是“最快的”的印象来自一个我们不再生活的时代。此外，node/js/v8从来就不是“快”的，而是它们打破了每请求一个线程的模型。其他人都在追赶。
如果您的目标是尽可能快地处理单个请求，那么请查看严肃的基准测试，而不是自己编写。但是，如果你想要的只是一些可以扩展到现代标准的东西，那么就选择你喜欢的任何语言，并确保你没有阻止这些线程。
免责声明：所有代码编写和测试都是在一个昏昏欲睡的星期天早上在老化的MacBook Air上运行的。随意抓取代码并在Windows上尝试或根据您的需要进行调整-https://github.com/csainty/nodejs-vs-aspnetcore

像Express和Koa这样的节点框架有很大的开销。“原始”节点明显更快。
我还没有尝试过，但是有一个更新的框架非常接近“原始”节点的性能：https://github.com/aerojs/aero
(see该页上的基准）
update：以下是一些数据：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

正如你所看到的，在最流行的node.js框架中，开销是非常大的！