我正在对两个用Node.js和ASP.NET-Core编写的hello world项目进行快速压力测试。它们都在生产模式下运行，并且没有连接记录器。结果令人瞠目结舌！即使做了一些额外的工作，ASP.NET核心的性能也超过了Node.js应用程序，而Node.js应用程序只是呈现一个视图。
使用:node.js，express和vash呈现引擎。
此endpoint中的代码为
router.get('/', function(req, res, next) {
var vm = {
title: 'Express',
time: new Date()
}
res.render('index', vm);
});
正如您所看到的，除了通过time变量向视图发送当前日期之外，它什么也不做。
使用: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();
}
更新:根据Gorgi Kosev的建议
使用npm安装-g recluster-cli&&NODE_ENV=生产重组-CLI app.js 8
不敢相信我的眼睛！在这个基本测试中，ASP.NET core比NodeJS快得多，这是不可能的。当然，这并不是用来衡量这两种web技术之间性能的唯一指标，但我想知道我在Node.js端做错了什么？。
作为一名专业的ASP.NET开发人员，希望在个人项目中采用Node.js，这有点让我望而却步--因为我对性能有点偏执。我认为Node.js比ASP.NET core快（总的来说--正如在其他各种基准测试中看到的那样），我只是想证明给自己看（鼓励自己适应Node.js）。
请在评论中回复，如果你想让我包括更多的代码片段。
更新:。NET核心应用程序的时间分布
服务器响应
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框架中，这种情况不会发生。
考虑这个node.js服务器，它在响应前等待1秒
const server = http.createServer((req, res) => {
setTimeout(() => {
res.statusCode = 200;
res.end();
}, 1000);
});
现在让我们向它抛出100个并发Connection，共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是“最快的”的印象来自于一个我们已经不在生活的时代。此外，Node/JS/V8从来不是“快”的，而是它们打破了线程/请求模型。其他人都在追赶。
如果您的目标是尽可能快地处理单个请求，那么请查看严肃的基准，而不是滚动您自己的基准。但是，如果您想要的只是可以扩展到现代标准的东西，那么就选择您喜欢的语言，并确保您没有阻塞那些线程。
免责声明:所有代码的编写和测试都是在一个令人昏昏欲睡的周日早晨在一台老化的MacBook Air上进行的。请随意获取代码并在Windows上试用，或根据您的需要进行调整-https://github.com/csainty/nodejs-vs-aspnetcore(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框架中的开销非常大！
