Node.js与ASP.NET Core性能测试的意外结果

200

我正在对两个(有点)hello world项目进行快速压力测试,它们都使用编写。它们都在生产模式下运行且没有附加日志记录器。结果令人惊讶!即使在执行一些额外工作后,ASP.NET Core的性能仍然优于node.js应用程序,而node.js应用程序只是渲染一个视图。

应用程序1:http://localhost:3000/nodejsnode.js

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

nodejs app

此端点中的代码为

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应用程序更重。

asp.net core app

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

[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 应用的压测结果

更新: 根据Gorgi Kosev的建议

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

nodejs test 2

ASP.NET Core 应用的压测结果

asp.net core stress test result

简直不敢相信!在这个基本的测试中,asp.net core比node.js快得多。当然,这不是衡量这两种Web技术性能的唯一标准,但我想知道我在node.js方面做错了什么?

作为一名专业的asp.net开发人员,希望将node.js应用于个人项目,这让我有些失落——因为我对性能有点儿偏执。我以为node.js比asp.net core更快(通常情况下——正如在其他各种基准测试中所看到的)。我只是想向自己证明这一点(以鼓励自己采用node.js)。

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

更新: .NET Core应用时间分布

aspnetcore app time distribution

服务器响应

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

67
我一直认为node.js比asp.net core更快 - 我很好奇您为什么这样认为?我没有看到任何支持这一观点的基准测试(采用node.js的主要原因是“易于使用”和“更快的开发/迭代时间”)。 - UnholySheep
8
@UnholySheep 这些都是我听到的伙计,我还听说它易于使用且开发速度更快,尤其是来自那些从未在ASP.NET和VisualStudio中工作过的人。我不是在夸耀任何技术,但这是我注意到的模式。 - undefined
3
这里的问题是什么?如果可以的话:是的,它是可行的。https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=plaintext .... 还要更新你的工具链,Dnxcore50已经过时一两年了。 - Thomas
3
@Tony 使用Node.js中的cluster模块启动多个worker并共享主进程的负载,该进程监听单一进程。这只是避免在不同端口上设置多个应用程序的方法。 如果Node.js以集群模式运行,则在IIS上应该有相同数量的Asp.Net Web应用程序在不同端口上运行,并通过某个负载均衡器在它们之间共享负载,那么这将是正确的比较。 - Vipresh
41
Node.js在许多方面都非常出色,但每个请求的原始速度不是它的强项。它擅长于作为I/O操作的代理,因为其采用了非阻塞事件循环机制,在Node.js刚推出时这是一大亮点。当然,自那以后其他语言和框架也跟上了步伐,例如.NET中的Task Parallel Library和异步I/O及async/await。由于Node.js是单线程JavaScript,因此它不擅长处理像页面渲染这样的CPU绑定操作。 - Mark Rendle
显示剩余24条评论
2个回答

210
正如其他人所提到的,这个比较缺乏背景信息。
在发布时,Node.js的异步方法是革命性的。此后,其他语言和Web框架开始采用他们的方法并使其成为主流。
要理解这种差异的含义,您需要模拟一个代表某些IO工作负载(例如数据库请求)的阻塞请求。在每个请求一个线程的系统中,这将耗尽线程池,并将新请求放入等待可用线程的队列中。 而非阻塞IO框架则不会出现这种情况。
考虑一下这个在1秒钟后才响应的Node.js服务器。
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代码,它是以异步/等待不被支持的方式编写的,因此将我们带回到了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

44
NodeJs从来不是独一无二的,请求线程模型在NodeJs出现之前也存在于Asp.Net中。所有进行I/O操作的方法都有两个版本,即同步和异步,由框架提供,它们的异步方法以关键字“Async”结尾,例如methodNameAsync。 - Vipresh
例如,您可以参考这篇关于数据库操作的文章,它可以追溯到2008年。 http://www.codedigest.com/Articles/ADO/173_ADONet_20_Features_-_Asynchronous_SqlCommand_Execution.aspx - Vipresh
6
“the approaches they took mainstream”意为“他们采取的方法变得主流”。几乎没有什么东西是独一无二的,这些方法让问题得到了更广泛的关注。拥有一个可用的方法和将其作为核心原则融入其中是两个非常不同的事情。 - Chris Sainty
4
这是最佳答案。没得说。 - Narvalex
3
@LeeBrindley 我不同意,这并不是试图展示给定硬件的最大吞吐量,而是展示阻塞和非阻塞之间的差异。如果您想要原始吞吐量比较,我会链接到techempower。 - Chris Sainty
显示剩余3条评论

13

像Express和Koa这样的Node框架存在严重的开销问题。而裸用Node速度明显更快。

虽然我没有尝试过,但有一个新的框架可以接近“裸”Node的性能: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框架中的开销非常显著!


12
这段话需要翻译成中文:“what are the numbers for? Higher the better?”这句话的意思是“数字有什么作用?数字越高越好吗?” - Iamisti

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接