关于C#：node.js与asp.net核心性能测试的意外结果


Unexpected outcome of node.js vs ASP.NET Core performance test

我正在对用node.js和asp.net-core编写的两个hello world项目进行快速压力测试。它们都在生产模式下运行，并且没有连接到它们的记录器。结果令人吃惊！即使在做了一些额外的工作之后，ASP.NET核心仍然比node.js应用出色，而node.js应用只是呈现一个视图。

附件1:http://localhost:3000/nodejsnode.js。

使用：node.js、express和vash渲染引擎。

nodejs app

此端点中的代码是

1
2
3
4
5
6
7
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 core，针对dnxcore50的默认模板

然而，这个应用程序除了渲染一个带有日期的页面外，还可以做其他事情。它生成5段不同的随机文本。理论上，这应该比Nodejs应用程序重一点。

asp.net core app

下面是呈现此页的操作方法

1
2
3
4
5
6
7
8
9
10
[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。

nodejs test 2

ASP.NET核心应用程序压力测试结果

asp.net core stress test result

不敢相信我的眼睛！在这个基本测试中，ASP.NET核心的速度远远快于nodejs是不可能的。当然，这并不是衡量这两种Web技术之间性能的唯一指标，但我想知道在node.js方面我做了什么错误？.

作为一个专业的ASP.NET开发人员，并且希望在个人项目中适应node.js，这有点让我感到厌烦——因为我对性能有点偏执。我认为node.js比asp.net核心更快(一般来说，如其他各种基准中所见)，我只是想向自己证明它(以鼓励自己适应node.js)。

如果您希望我包含更多的代码段，请在评论中回复。

更新：.NET核心应用程序的时间分布

aspnetcore app time distribution

服务器响应

1
2
3
4
5
6
7
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工作负载的阻塞请求，例如数据库请求。在每个请求系统的线程中，这将耗尽线程池，新请求将放入队列，等待可用线程。对于非阻塞IO框架，不会发生这种情况。

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

1
2
3
4
5
6
const server = http.createServer((req, res) => {
  setTimeout(() => {
    res.statusCode = 200;
    res.end();
  }, 1000);
});

现在让我们向它抛出100个并发连接，持续10秒，所以我们期望完成大约1000个请求。

1
2
3
4
5
6
7
8
9
$ 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代码，它编写起来好像还不支持异步/等待，因此可以追溯到node.js的发布时代。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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绑定的工作负载，避免阻塞处理线程的做法是非常引人注目的。

现在让我们把它带到今天，在那里，这种影响已经波及整个行业，并允许互联网利用其改进。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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是"最快"的印象来自于我们不再生活的时代。除此之外，它从来不是节点/JS/V8的"快速"，而是它们打破了每个请求模型的线程。其他人都在追赶。

如果您的目标是处理单个请求的最快速度，那么请查看重要的基准，而不是滚动您自己的基准。但是，如果你想要的只是一些可以扩展到现代标准的东西，那么就使用你喜欢的任何语言，并确保你没有阻塞那些线程。

免责声明：在一个沉睡的周日早晨，所有代码都是在一台老化的MacBookAir上编写的，并且测试运行。随意获取代码并在Windows上试用，或者根据您的需要进行调整-https://github.com/csainty/nodejs-vs-aspnetcore

相关讨论

像express和koa这样的节点框架的开销非常大。""原始"节点明显更快。

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

(见该页的基准)

更新：以下是一些图：https://github.com/blitzprog/webserver-benchedges

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
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框架中的开销非常大！

相关讨论