node.js vs ASP.NET Core 性能测试的意外结果

正如许多其他人所暗示的那样，这种比较缺乏背景。在其发布时，node.js 的异步方法是革命性的。从那时起，其他语言和 Web 框架一直在采用它们成为主流的方法。

要了解差异意味着什么，您需要模拟一个代表一些 IO 工作负载的阻塞请求，例如数据库请求。在每个请求线程系统中，这将耗尽线程池，并且新请求将被放入等待可用线程的队列中。对于非阻塞 io 框架，这不会发生。

考虑这个在响应前等待 1 秒的 node.js 服务器

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

现在让我们在 10 秒内抛出 100 个并发连接。因此，我们预计完成大约 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 是“快”的，而是它们破坏了每个请求的线程模型。其他人都在追赶。

如果您的目标是尽可能快地处理单个请求，请查看 serious benchmarks 而不是自己动手。但是，如果您想要的只是符合现代标准的东西，那么请选择您喜欢的任何语言，并确保您没有阻塞这些线程。

免责声明：在一个昏昏欲睡的星期天早上，在老化的 MacBook Air 上编写和运行所有代码。随意获取代码并在 Windows 上试用或根据您的需要进行调整 - https://github.com/csainty/nodejs-vs-aspnetcore

像 Express 和 Koa 这样的节点框架有一个可怕的开销。 “原始”节点明显更快。

我没有尝试过，但有一个更新的框架非常接近“原始”节点性能：https://github.com/aerojs/aero

（请参阅该页面上的基准）

更新：以下是一些数字：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 框架的开销非常大！