node.js 与 ASP.NET 核心性能测试的意外结果
Unexpected outcome of node.js vs ASP.NET Core performance test
我正在对用 node.js and asp.net-core 编写的两个（有点）hello world 项目进行快速压力测试。它们都处于生产模式 运行，并且没有附加记录器。结果令人震惊！ ASP.NET 核心性能优于 node.js 应用程序，即使在做了一些额外的工作之后 node.js 应用程序只是呈现一个视图。
应用 1：http://localhost:3000/nodejsnode.js
使用: node.js, express 和 vash 渲染引擎。
此端点中的代码是
router.get('/', function(req, res, next) {
var vm = {
title: 'Express',
time: new Date()
}
res.render('index', vm);
});
如您所见，除了通过 time 变量将当前日期发送到视图之外，它什么也不做。
应用 2：http://localhost:5000/aspnet-coreasp.net core
使用：ASP.NET核心，默认模板定位dnxcore50
然而，这个应用程序除了呈现一个带有日期的页面之外还有其他功能。它生成 5 段各种随机文本。这在理论上应该比 nodejs 应用程序稍微重一点。
这是呈现此页面的操作方法
[ResponseCache(Location = ResponseCacheLocation.None, NoStore = true)]
[Route("aspnet-core")]
public IActionResult Index()
{
var sb = new StringBuilder(1024);
GenerateParagraphs(5, sb);
ViewData["Message"] = sb.ToString();
return View();
}
压力测试结果
Node.js 应用压力测试结果
更新：
使用npm install -g recluster-cli && NODE_ENV=production recluster-cli app.js 8
ASP.NET核心应用压力测试结果
简直不敢相信自己的眼睛！在这个基本测试中 asp.net core 比 nodejs 快得多是不可能的。当然，这不是衡量这两种网络技术之间性能的唯一指标，但我想知道 我在 node.js 方面做错了什么？.
作为一名专业的 asp.net 开发人员并希望在个人项目中进行调整 node.js，这有点让我失望 - 因为我对性能有点偏执。我认为 node.js 比 asp.net 核心快（一般来说 - 正如在其他各种基准测试中所见）我只是想向自己证明这一点（鼓励自己适应 node.js）。
如果您希望我包含更多代码片段，请在评论中回复。
更新：
.NET Core 应用的时间分布
服务器响应
HTTP/1.1 200 OK
Cache-Control: no-store,no-cache
Date: Fri, 12 May 2017 07:46:56 GMT
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
Server: Kestrel
正如许多其他人所暗示的那样，这种比较缺乏上下文。
在发布时，node.js 的异步方法是革命性的。从那时起，其他语言和 Web 框架一直在采用它们成为主流的方法。
要了解差异的含义，您需要模拟代表某些 IO 工作负载的阻塞请求，例如数据库请求。在 thread-per-request 系统中，这将耗尽线程池，新请求将被放入等待可用线程的队列中。
对于非阻塞 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 是 "fastest" 的印象来自一个我们不再生活的时代。此外，node/js/v8 从来不是 "fast"，是他们打破了每个请求一个线程的模型。其他人都在追赶。
如果您的目标是尽可能快地处理单个请求，请查看 serious benchmarks 而不是自己滚动。但是，如果您想要的只是可以扩展到现代标准的东西，那么请选择您喜欢的任何一种语言，并确保您不会阻塞这些线程。
免责声明：在一个昏昏欲睡的星期天早晨，所有代码都在老化的 MacBook Air 上编写和测试 运行。随时获取代码并在 Windows 上试用或根据您的需要进行调整 - https://github.com/csainty/nodejs-vs-aspnetcore
Express 和 Koa 等节点框架的开销非常大。 "Raw" Node 明显更快。
我没试过，但是有一个更新的框架非常接近 "Raw" 节点性能：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 框架的开销非常大！
我正在对用 node.js and asp.net-core 编写的两个（有点）hello world 项目进行快速压力测试。它们都处于生产模式 运行，并且没有附加记录器。结果令人震惊！ ASP.NET 核心性能优于 node.js 应用程序，即使在做了一些额外的工作之后 node.js 应用程序只是呈现一个视图。
应用 1：http://localhost:3000/nodejsnode.js
使用: node.js, express 和 vash 渲染引擎。
此端点中的代码是
router.get('/', function(req, res, next) {
var vm = {
title: 'Express',
time: new Date()
}
res.render('index', vm);
});
如您所见，除了通过 time 变量将当前日期发送到视图之外，它什么也不做。
应用 2：http://localhost:5000/aspnet-coreasp.net core
使用：ASP.NET核心，默认模板定位dnxcore50
然而，这个应用程序除了呈现一个带有日期的页面之外还有其他功能。它生成 5 段各种随机文本。这在理论上应该比 nodejs 应用程序稍微重一点。
这是呈现此页面的操作方法
[ResponseCache(Location = ResponseCacheLocation.None, NoStore = true)]
[Route("aspnet-core")]
public IActionResult Index()
{
var sb = new StringBuilder(1024);
GenerateParagraphs(5, sb);
ViewData["Message"] = sb.ToString();
return View();
}
压力测试结果
Node.js 应用压力测试结果
更新：
使用npm install -g recluster-cli && NODE_ENV=production recluster-cli app.js 8
ASP.NET核心应用压力测试结果
简直不敢相信自己的眼睛！在这个基本测试中 asp.net core 比 nodejs 快得多是不可能的。当然，这不是衡量这两种网络技术之间性能的唯一指标，但我想知道 我在 node.js 方面做错了什么？.
作为一名专业的 asp.net 开发人员并希望在个人项目中进行调整 node.js，这有点让我失望 - 因为我对性能有点偏执。我认为 node.js 比 asp.net 核心快（一般来说 - 正如在其他各种基准测试中所见）我只是想向自己证明这一点（鼓励自己适应 node.js）。
如果您希望我包含更多代码片段，请在评论中回复。
更新： .NET Core 应用的时间分布
服务器响应
HTTP/1.1 200 OK
Cache-Control: no-store,no-cache
Date: Fri, 12 May 2017 07:46:56 GMT
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
Server: Kestrel
正如许多其他人所暗示的那样，这种比较缺乏上下文。
在发布时，node.js 的异步方法是革命性的。从那时起，其他语言和 Web 框架一直在采用它们成为主流的方法。
要了解差异的含义，您需要模拟代表某些 IO 工作负载的阻塞请求，例如数据库请求。在 thread-per-request 系统中，这将耗尽线程池，新请求将被放入等待可用线程的队列中。
对于非阻塞 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 是 "fastest" 的印象来自一个我们不再生活的时代。此外，node/js/v8 从来不是 "fast"，是他们打破了每个请求一个线程的模型。其他人都在追赶。
如果您的目标是尽可能快地处理单个请求，请查看 serious benchmarks 而不是自己滚动。但是，如果您想要的只是可以扩展到现代标准的东西，那么请选择您喜欢的任何一种语言，并确保您不会阻塞这些线程。
免责声明：在一个昏昏欲睡的星期天早晨，所有代码都在老化的 MacBook Air 上编写和测试 运行。随时获取代码并在 Windows 上试用或根据您的需要进行调整 - https://github.com/csainty/nodejs-vs-aspnetcore
Express 和 Koa 等节点框架的开销非常大。 "Raw" Node 明显更快。
我没试过，但是有一个更新的框架非常接近 "Raw" 节点性能：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 框架的开销非常大！