node.js 대 ASP.NET Core 성능 테스트의 예기치 않은 결과
node.js 및 asp.net-core로 작성된 두 개의 (kinda) hello world 프로젝트에 대해 빠른 스트레스 테스트를 수행 하고 있습니다 . 둘 다 프로덕션 모드에서 실행되고 로거가 첨부되지 않았습니다. 결과는 놀랍습니다! ASP.NET 코어는 추가 작업을 한 후에도 node.js 앱보다 성능이 뛰어나며 node.js 앱은 뷰를 렌더링합니다.
앱 1 : http://localhost:3000/nodejs node.js
사용 : node.js, 표현 및 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 앱 스트레스 테스트 결과
업데이트 : Gorgi Kosev의 제안에 따라
사용 npm install -g recluster-cli && NODE_ENV=production recluster-cli app.js 8
ASP.NET Core App 스트레스 테스트 결과
내 눈을 믿을 수 없어! 이 기본 테스트에서 asp.net 코어가 nodejs보다 훨씬 빠르다는 것은 사실이 아닙니다. 물론이 두 웹 기술 간의 성능을 측정하는 데 사용되는 유일한 메트릭은 아니지만 node.js 측에서 내가 뭘 잘못하고 있는지 궁금 합니다. .
Being a professional asp.net developer and wishing to adapt node.js in personal projects, this is kind of putting me off - as I'm a little paranoid about performance. I thought node.js is faster than asp.net core (in general - as seen in various other benchmarks) I just want to prove it to myself (to encourage myself in adapting node.js).
Please reply in comment if you want me to include more code snippets.
Update: Time distribution of .NET Core app
Server response
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
As many others have alluded, the comparison lacks context.
At the time of its release, the async approach of node.js was revolutionary. Since then other languages and web frameworks have been adopting the approaches they took mainstream.
To understand what the difference meant, you need to simulate a blocking request that represents some IO workload, such as a database request. In a thread-per-request system, this will exhaust the threadpool and new requests will be put in to a queue waiting for an available thread.
With non-blocking-io frameworks this does not happen.
Consider this node.js server that waits 1 second before responding
const server = http.createServer((req, res) => {
setTimeout(() => {
res.statusCode = 200;
res.end();
}, 1000);
});
Now let's throw 100 concurrent conenctions at it, for 10s. So we expect about 1000 requests to complete.
$ 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
As you can see we get in the ballpark with 922 completed.
Now consider the following asp.net code, written as though async/await were not supported yet, therefore dating us back to the node.js launch era.
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! Here we see the limit of the threadpool. By tuning it up we could get more concurrent requests happening, but at the cost of more server resources.
For these IO-bound workloads, the move to avoid blocking the processing threads was that dramatic.
Now let's bring it to today, where that influence has rippled through the industry and allow dotnet to take advantage of its improvements.
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
No surprises here, we now match node.js.
So what does all this mean?
Your impressions that node.js is the "fastest" come from an era we are no longer living in. Add to that it was never node/js/v8 that were "fast", it was that they broke the thread-per-request model. Everyone else has been catching up.
If your goal is the fastest possible processing of single requests, then look at the serious benchmarks instead of rolling your own. But if instead what you want is simply something that scales to modern standards, then go for whichever language you like and make sure you are not blocking those threads.
Disclaimer: All code written, and tests run, on an ageing MacBook Air during a sleepy Sunday morning. Feel free to grab the code and try it on Windows or tweak to your needs - https://github.com/csainty/nodejs-vs-aspnetcore
Node Frameworks like Express and Koa have a terrible overhead. "Raw" Node is significantly faster.
I haven't tried it, but there's a newer framework that gets very close to "Raw" Node performance: 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 프레임 워크의 오버 헤드는 매우 중요합니다!
'Programming' 카테고리의 다른 글
| 작동하는 C ++ 리팩토링 도구가 있습니까? (0) | 2020.06.03 |
|---|---|
| .vcxproj.filter 파일을 소스 제어에 추가해야합니까? (0) | 2020.06.03 |
| 디버거는 어떻게 작동합니까? (0) | 2020.06.03 |
| 반응 구성 요소 외부에서 Redux Store에 액세스하는 가장 좋은 방법은 무엇입니까? (0) | 2020.06.03 |
| 'for'루프에서 마지막 요소를 감지하는 pythonic 방법은 무엇입니까? (0) | 2020.06.03 |




