node.js与ASP.NET核心性能测试的意外结果

und*_*ned 164 c# performance stress-testing node.js asp.net-core

我正在用编写的两个(有点)hello world项目进行快速压力测试.它们都在生产模式下运行,并且没有连接记录器.结果令人惊讶!即使在做了一些额外的工作之后,ASP.NET核心也优于node.js应用程序,而node.js应用程序只是渲染视图.

应用1: http://localhost:3000/nodejs node.js

使用:node.js,express和vash渲染引擎.

nodejs app

此端点中的代码是

router.get('/', function(req, res, next) {
  var vm = {
    title: 'Express',
    time: new Date()
  }
  res.render('index', vm);
});
Run Code Online (Sandbox Code Playgroud)

正如您所看到的,除了通过time变量将当前日期发送到视图之外,它什么也没做.

应用2: http://localhost:5000/aspnet-core asp.net core

使用:ASP.NET Core,默认模板定位dnxcore50

然而,这个应用程序不仅仅是渲染一个带有日期的页面.它生成5段各种随机文本.从理论上讲,这应该比nodejs app重一点.

asp.net核心应用程序

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

[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();
}
Run Code Online (Sandbox Code Playgroud)

压力测试结果

Node.js App压力测试结果

更新:遵循Gorgi Kosev的建议

运用 npm install -g recluster-cli && NODE_ENV=production recluster-cli app.js 8

nodejs测试2

ASP.NET Core App压力测试结果

asp.net核心压力测试结果

不敢相信自己的眼睛!在这个基本测试中,asp.net核心比nodejs更快,这是不正确的.当然,这不是衡量这两种网络技术之间性能的唯一指标,但我想知道我在node.js方面做错了什么?.

作为一个专业的asp.net开发人员,并希望在个人项目中适应node.js,这有点让我失望 - 因为我对性能有点偏执.我认为node.js比asp.net核心更快(一般来说 - 如各种其他基准测试中所见)我只是想向自己证明这一点(鼓励自己适应node.js).

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

更新: .NET Core应用程序的时间分配

aspnetcore应用程序时间分配

服务器响应

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
Run Code Online (Sandbox Code Playgroud)

Chr*_*nty 173

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

要了解差异的含义,您需要模拟代表某些IO工作负载的阻塞请求,例如数据库请求.在每个请求线程系统中,这将耗尽线程池,并且新请求将被放入等待可用线程的队列中.
使用非阻塞io框架,这不会发生.

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

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

现在让我们在它上面投入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
Run Code Online (Sandbox Code Playgroud)

正如你所看到的那样,我们完成了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
Run Code Online (Sandbox Code Playgroud)

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
Run Code Online (Sandbox Code Playgroud)

这里没有惊喜,我们现在匹配node.js.

那么,这意味着什么?

你对node.js是"最快的"的印象来自我们不再生活的时代.再加上它从来就不是node/js/v8那么"快",而是他们打破了每个请求的线程模型.其他人都在追赶.

如果您的目标是尽可能快地处理单个请求,那么请查看严格的基准测试,而不是自行编写.但是,如果您想要的只是符合现代标准的东西,那么请选择您喜欢的任何语言,并确保您不会阻止这些线程.

免责声明:在昏昏欲睡的周日早晨,所有代码都在老化的MacBook Air上编写和测试.随意获取代码并在Windows上试用或调整以满足您的需求 - https://github.com/csainty/nodejs-vs-aspnetcore

  • NodeJs从来都不是唯一的,在引入nodejs之前,每个请求模型的模型也存在于Asp.Net中.所有执行I/O的方法都有两个版本同步和Framework提供的异步,它们的ASYNC方法以关键字"Async"结尾例如.methodNameAsync (31认同)
  • "他们采取主流的方法" - 很少有东西是独一无二的,他们把问题放在更广泛的受众面前.提供一种方法,并将其作为核心原则进行烘焙是两个截然不同的事情. (4认同)
  • 这里最好的答案.期. (4认同)
  • @LeeBrindley我不同意,这不是试图证明给定硬件的最大吞吐量,而是展示了阻塞和非阻塞之间的区别.如果您想要原始吞吐量比较,我链接到techempower. (3认同)

smo*_*rgs 12

像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
Run Code Online (Sandbox Code Playgroud)

如您所见,最流行的node.js框架中的开销非常重要!

  • 这个数字是多少?越高越好? (5认同)