【问题标题】：Unexpected outcome of node.js vs ASP.NET Core performance testnode.js vs ASP.NET Core 性能测试的意外结果
【发布时间】：2017-10-10 18:46:52
【问题描述】：

我正在对用node.js 和asp.net-core 编写的两个（有点）hello world 项目进行快速压力测试。它们都在生产模式下运行，并且没有附加记录器。结果是惊人的！即使在做了一些额外的工作之后，ASP.NET 核心的性能也优于 node.js 应用程序，而 node.js 应用程序只是呈现一个视图。

应用程序 1：`http://localhost:3000/nodejs` `node.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-core` `asp.net core`

使用：ASP.NET Core，默认模板定位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 App压力测试结果

更新：Following suggestion by Gorgi Kosev

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

ASP.NET Core App压力测试结果

不敢相信我的眼睛！在这个基本测试中，asp.net core 比 nodejs 快得多，这不是真的。当然，这不是用于衡量这两种 Web 技术之间性能的唯一指标，但我想知道 我在 node.js 方面做错了什么？。

作为一名专业的 asp.net 开发人员并希望在个人项目中使用 node.js，这有点让我望而却步——因为我对性能有点偏执。我认为 node.js 比 asp.net core 更快（一般来说 - 正如在其他各种基准测试中看到的那样）我只是想向自己证明一下（鼓励自己适应 node.js）。

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

更新： .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 比 asp.net core 快” - 我很好奇你为什么这么认为？我还没有看到任何支持这一点的基准（我听说采用 node.js 的主要原因是“易于使用”和“更快的开发/迭代时间”）
@UnholySheep 这都是我听到的，我也听说它“易于使用”和“开发速度更快”，通常来自人们从未在 ASP.NET 中工作过，尤其是在 VisualStudio 中。我不是在吹嘘任何技术——但这是我注意到的模式。
这里的问题是什么？如果它是合理的：是的。 techempower.com/benchmarks/… .... 还要更新你的工具链 Dnxcore50 已经过时了至少一两年。
@Tony 使用集群模块 NodeJs 产生多个工作人员，并分担正在侦听单个进程的主进程的负载。它只是避免了在不同的端口上设置多个应用程序。此外，如果 nodeJs 在集群模式下运行，那么应该有相同数量的 Asp.Net WebApplications 在 IIS 上运行在不同的端口上，并通过一些负载均衡器在它们之间共享负载，那么这将是正确的比较。
Node.js 非常适合做很多事情，但每个请求的原始速度并不是其中之一。它擅长的是作为 I/O 操作的代理，因为非阻塞事件循环的东西，当 Node 是新的和闪亮的时候，这是一件大事。当然，从那时起，其他语言和框架也赶上了，所以在 .NET 中，我们有了任务并行库和异步 I/O 和 async/await。 Node 不擅长的是页面渲染等 CPU 密集型操作，因为它是单线程 JavaScript。

标签： node.js asp.net-core c# node.js performance asp.net-core stress-testing

【解决方案1】：

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

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

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

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

【讨论】：

NodeJs 从来都不是唯一的，在引入 nodejs 之前，Asp.Net 中也存在按请求线程模型。所有进行 I/O 的方法都有框架提供的同步和异步 2 个版本，它们的 ASYNC以关键字“Async”结尾的方法，例如。方法名异步
例如。可以参考这篇2008年数据库操作相关的文章codedigest.com/Articles/ADO/…
“他们采用主流的方法” - 很少有东西是独一无二的，他们将这个问题摆在更广泛的受众面前。拥有一种可用的方法，并将其作为核心原则纳入其中是两件截然不同的事情。
最佳答案在这里。期间。
@LeeBrindley 我不同意，这并不是要展示给定硬件的最大吞吐量，而是展示阻塞和非阻塞之间的区别。如果您想要原始吞吐量比较，我链接到 techempower。

【解决方案2】：

像 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 框架的开销非常大！