我正在对两个(有点)用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核心,针对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应用程序压力测试结果
更新:Following suggestion by Gorgi Kosev
使用npm install -g recluster-cli && NODE_ENV=production recluster-cli app.js 8
ASP.NET核心应用压力测试结果
真不敢相信我的眼睛!在这个基本的测试中,asp.net内核比nodejs快得多,这是不可能的。当然,这并不是用来衡量这两种web技术之间性能的唯一指标,但我想知道我在node.js方面做错了什么?。
作为一名专业的asp.net开发人员,并希望在个人项目中适应node.js,这让我有点反感--因为我对性能有点偏执。我认为node.js比asp.net核心更快(一般来说-从其他各种基准测试中可以看出),我只是想向自己证明这一点(鼓励自己适应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
发布于 2017-05-21 14:04:45
正如许多其他人所暗示的那样,这种比较缺乏背景。
在它发布的时候,node.js的异步方法是革命性的。从那时起,其他语言和web框架一直在采用它们所采用的主流方法。
要理解这种差异意味着什么,您需要模拟一个代表一些IO工作负载的阻塞请求,比如数据库请求。在每请求一个线程的系统中,这将耗尽线程池,新的请求将被放入一个队列中,等待可用的线程。
对于非阻塞-io框架,这种情况不会发生。
假设此node.js服务器在响应前等待1秒
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从来都不是“快”的,而是它们打破了每请求线程模型。其他人都在迎头赶上。
如果您的目标是尽可能快地处理单个请求,那么请查看serious benchmarks,而不是滚动您自己的own。但是,如果你想要的仅仅是可以扩展到现代标准的东西,那么选择你喜欢的任何语言,并确保你没有阻塞这些线程。
免责声明:在一个昏昏欲睡的星期天早上,所有编写的代码和测试都是在老化的MacBook Air上运行的。请随意获取代码并在Windows上试用,或根据需要进行调整-- https://github.com/csainty/nodejs-vs-aspnetcore
发布于 2017-06-13 02:50:48
像Express和Koa这样的节点框架有一个可怕的开销。"Raw“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框架的开销非常大!
https://stackoverflow.com/questions/43920942
复制相似问题