node.js 대 ASP의 예기치 않은 결과입니다.NET Core 성능 테스트

node.js 대 ASP의 예기치 않은 결과입니다.NET Core 성능 테스트

저는 node.js와 asp.net -core로 작성된 두 개의 hello world 프로젝트에 대해 빠른 스트레스 테스트를 하고 있습니다.두 제품 모두 로거가 연결되지 않은 상태에서 프로덕션 모드로 실행되고 있습니다.결과는 놀랍습니다! ASP.NET core는 node.js app보다 성능이 뛰어나며 node.js app은 보기만 렌더링합니다.

앱 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 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 App 스트레스 테스트 결과

업데이트: Gorgi Kosev의 제안에 따라.

사용.npm install -g recluster-cli && NODE_ENV=production recluster-cli app.js 8

ASP.NET Core App 스트레스 테스트 결과

내 눈을 믿을 수가 없어요!이 기본 테스트에서 asp.net 코어가 nodejs보다 훨씬 빠르다는 것은 사실일 수 없습니다.물론 이 두 웹 기술 사이의 성능을 측정하는 데 사용되는 유일한 메트릭은 아니지만, 제가 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의 비동기식 접근 방식은 혁신적이었습니다.그 이후로 다른 언어와 웹 프레임워크는 주류를 이루는 접근 방식을 채택하고 있습니다.

차이점이 의미하는 바를 이해하려면 데이터베이스 요청과 같은 일부 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 코드를 생각해 보십시오. 따라서 우리는 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 제한 워크로드의 경우, 처리 스레드를 차단하지 않기 위한 움직임이 매우 극적이었습니다.

이제 이러한 영향력이 업계 전반에 파급되어 온 오늘날의 상황을 살펴보겠습니다. 그리고 닷넷이 그 개선점을 활용할 수 있게 해줍니다.

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이 아니라 요청당 스레드 모델이 깨졌다는 것입니다.다른 사람들은 다 따라잡았어요.

단일 요청을 가능한 한 빨리 처리하는 것이 목표라면 자체적으로 처리하는 것이 아니라 중요한 벤치마크를 살펴보십시오.하지만 만약 당신이 원하는 것이 단순히 현대 표준에 맞게 확장되는 것이라면, 당신이 좋아하는 언어를 선택하고 그러한 스레드를 차단하지 않도록 하라.

고지 사항:모든 코드가 작성되고 테스트가 맥북 에어의 노후화된 일요일 아침에 실행됩니다.코드를 가져와 Windows에서 사용해 보거나 필요에 맞게 수정하십시오. - 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 프레임워크의 오버헤드는 매우 중요합니다!

언급URL : https://stackoverflow.com/questions/43920942/unexpected-outcome-of-node-js-vs-asp-net-core-performance-test