我正在对用node.js和asp.net-core编写的两个(有点)hello world 项目进行快速压力测试。它们都在生产模式下运行,并且没有附加记录器。结果是惊人的!即使在做了一些额外的工作之后,ASP.NET 核心的性能也优于 node.js 应用程序,而 node.js 应用程序只是呈现一个视图。
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变量将当前日期发送到视图之外,它什么也不做。
time
http://localhost:5000/aspnet-core
asp.net core
使用 :ASP.NET Core,默认模板定位dnxcore50
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 install -g recluster-cli && NODE_ENV=production recluster-cli app.js 8
npm install -g recluster-cli && NODE_ENV=production recluster-cli app.js 8
简直不敢相信我的眼睛!在这个基本测试中,asp.net core 比 nodejs 快得多,这不是真的。当然,这不是用于衡量这两种 Web 技术之间性能的唯一指标,但我想 知道我在 node.js 方面做错了什么?.
作为一名专业的 asp.net 开发人员并希望在个人项目中使用 node.js,这有点让我失望——因为我对性能有点偏执。我认为 node.js 比 asp.net core 更快(通常 - 正如在其他各种基准测试中看到的那样)我只是想向自己证明一下(鼓励自己适应 node.js)。
如果您希望我包含更多代码片段,请在评论中回复。
更新: .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 的异步方法是革命性的。从那时起,其他语言和 Web 框架一直在采用它们成为主流的方法。
要了解差异意味着什么,您需要模拟一个代表一些 IO 工作负载的阻塞请求,例如数据库请求。在每个请求线程系统中,这将耗尽线程池,并且新请求将被放入等待可用线程的队列中。 对于非阻塞 io 框架,这不会发生。
考虑这个在响应前等待 1 秒的 node.js 服务器
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 是“快”的,而是它们破坏了每个请求的线程模型。其他人都在追赶。
如果您的目标是尽可能快地处理单个请求,那么请查看严肃的基准,而不是自己动手。但是,如果您想要的只是符合现代标准的东西,那么请选择您喜欢的任何语言,并确保您没有阻塞这些线程。
免责声明:在一个昏昏欲睡的星期天早上,在老化的 MacBook Air 上编写和运行所有代码。随意获取代码并在 Windows 上尝试或根据您的需要进行调整 - https://github.com/csainty/nodejs-vs- aspnetcore