ผลลัพธ์ที่ไม่คาดหมายของ node.js กับการทดสอบประสิทธิภาพ ASP.NET Core


177

ฉันกำลังทำแบบทดสอบความเครียดฉบับย่อเกี่ยวกับโครงการสวัสดีชาวโลกสองโครงการ และ . ทั้งสองกำลังทำงานในโหมดการผลิตและไม่มีคนตัดไม้ที่แนบมากับพวกเขา ผลที่ได้คือน่าอัศจรรย์! ASP.NET core นั้นมีประสิทธิภาพที่เหนือกว่าแอป node.js แม้หลังจากทำงานพิเศษบางอย่างแล้วในขณะที่แอป node.js ก็แค่แสดงผลมุมมอง

แอพ 1: http://localhost:3000/nodejs node.js

การใช้ : node.js, เอ็นจิ้นการแสดงผลด่วนและ vash

แอป nodejs

รหัสในจุดสิ้นสุดนี้คือ

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

นี่คือวิธีการกระทำที่แสดงหน้านี้

[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 ทดสอบ 2

ผลการทดสอบความเค้น ASP.NET Core App

ผลการทดสอบความเครียดแกน asp.net

ไม่อยากเชื่อสายตาของฉัน! ไม่เป็นความจริงเลยที่ core asp.net ในการทดสอบพื้นฐานนี้จะเร็วกว่า nodejs แน่นอนว่านี่ไม่ใช่ตัวชี้วัดเดียวที่ใช้ในการวัดประสิทธิภาพระหว่างเทคโนโลยีเว็บทั้งสองนี้ แต่ฉันสงสัยว่าฉันกำลังทำอะไรผิดในทางด้าน node.js? .

การเป็นนักพัฒนา asp.net มืออาชีพและต้องการปรับเปลี่ยน node.js ในโครงการส่วนบุคคลนี่เป็นสิ่งที่ทำให้ฉันเลิกเพราะฉันเป็นคนหวาดระแวงเล็กน้อยเกี่ยวกับประสิทธิภาพ ฉันคิดว่า node.js เร็วกว่าแกน asp.net (โดยทั่วไป - ตามที่เห็นในมาตรฐานอื่น ๆ ) ฉันแค่ต้องการพิสูจน์ให้ตัวเอง (เพื่อส่งเสริมตัวเองในการปรับเปลี่ยน node.js)

โปรดตอบในความคิดเห็นหากคุณต้องการให้ฉันใส่ข้อมูลโค้ดเพิ่มเติม

อัปเดต: การกระจายเวลาของแอป. NET Core

การกระจายเวลาแอป aspnetcore

การตอบสนองของเซิร์ฟเวอร์

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

52
"ฉันคิดเสมอว่า node.js เร็วกว่าแกน asp.net" - ฉันสงสัยว่าทำไมคุณคิดอย่างนั้น? ฉันไม่เห็นมาตรฐานใด ๆ ที่จะสนับสนุนสิ่งนี้ (เหตุผลหลักที่ฉันเคยได้ยินเกี่ยวกับการใช้ node.js คือ "ใช้งานง่าย" และ "การพัฒนาเร็วขึ้น / เวลาการทำซ้ำ")
UnholySheep

7
@ UnholySheep มันคือทั้งหมดที่ฉันได้ยินเพื่อนฉันก็ได้ยินว่า "ใช้งานง่าย" และ "เร็วกว่าการพัฒนา" ด้วยโดยทั่วไปจากคนใช้ไม่เคยทำงานใน ASP.NET โดยเฉพาะใน VisualStudio ฉันไม่ได้โม้เกี่ยวกับเทคโนโลยีใด ๆ - แต่นี่เป็นรูปแบบที่ฉันสังเกตเห็น
ไม่ได้กำหนด

3
คำถามที่นี่คืออะไร ถ้าเป็นไปได้: ใช่ techempower.com/benchmarks/ ...... .... อัปเดต toolchain ของคุณ Dnxcore50 ล้าสมัยอย่างน้อยปีหรือสองปี
โทมัส

2
@Tony โดยใช้โมดูลคลัสเตอร์ NodeJs วางไข่หลายคนทำงานและแบ่งปันภาระของกระบวนการหลักที่กำลังฟังในกระบวนการเดียว หลีกเลี่ยงการตั้งค่าแอปพลิเคชั่นหลายตัวบนพอร์ตที่แตกต่างกัน นอกจากนี้ถ้า nodeJs กำลังทำงานในโหมดคลัสเตอร์ดังนั้น Asp.Net WebApplications จำนวนเท่ากันควรทำงานใน IIS บนพอร์ตต่าง ๆ และแบ่งปันโหลดระหว่างพวกเขาผ่านตัวโหลดบาลานเซอร์บางตัวมันจะเป็นการเปรียบเทียบที่ถูกต้อง
Vipresh

36
Node.js นั้นยอดเยี่ยมสำหรับสิ่งต่าง ๆ มากมาย แต่ความเร็วที่แท้จริงต่อคำขอไม่ได้เป็นหนึ่งในนั้น สิ่งที่ดีคือการเป็นนายหน้าสำหรับการดำเนินงาน I / O เนื่องจากสิ่งที่ไม่ปิดกั้นเหตุการณ์วงซึ่งเมื่อโหนดเป็นใหม่และเงางามเป็นเรื่องใหญ่ แน่นอนตั้งแต่นั้นภาษาและกรอบงานอื่น ๆ ได้รับการแก้ไขดังนั้นใน. NET เรามี Task Parallel Library และ I / O อะซิงโครนัสและ async / await สิ่งที่โหนดไม่เก่งที่มีการทำงานของ CPU เช่นการแสดงผลหน้าเพราะมันเป็นจาวาสคริปต์แบบเธรดเดียว
Mark Rendle

คำตอบ:


188

ตามที่คนอื่น ๆ หลายคนพูดพาดพิงการเปรียบเทียบไม่มีบริบท
ในช่วงเวลาของการเปิดตัววิธีการ async ของ node.js เป็นการปฏิวัติ ตั้งแต่นั้นภาษาอื่น ๆ และกรอบเว็บได้รับการใช้วิธีการที่พวกเขาใช้เป็นหลัก

เพื่อให้เข้าใจถึงความแตกต่างที่มีความหมายคุณต้องจำลองคำขอการบล็อกที่แสดงถึงภาระงานของ IO บางอย่างเช่นคำขอฐานข้อมูล ในระบบแบบเธรดต่อคำร้องขอสิ่งนี้จะทำให้เธรดพูลหมดลงและคำร้องขอใหม่จะถูกใส่ในคิวที่รอเธรดที่พร้อมใช้งาน
ด้วยเฟรมเวิร์กที่ไม่มีการบล็อคไอโอสิ่งนี้จะไม่เกิดขึ้น

พิจารณาเซิร์ฟเวอร์ node.js นี้ที่รอ 1 วินาทีก่อนตอบกลับ

const server = http.createServer((req, res) => {
  setTimeout(() => {
    res.statusCode = 200;
    res.end();
  }, 1000);
});

ทีนี้ลองโยนโครเชต์พร้อมกัน 100 อันมาเป็น 10 วินาที ดังนั้นเราคาดว่าจะมีคำขอ 1,000 คำขอให้เสร็จสมบูรณ์

$ 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

อย่างที่คุณเห็นเราเข้าไปใน ballpark กับ 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 เป็น "เร็วที่สุด" มาจากยุคที่เราไม่ได้อยู่อีกต่อไปเพิ่มไปที่โหนด / js / v8 ที่ไม่เคย "เร็ว" นั่นคือพวกเขาทำลายเธรดต่อคำขอ แบบ คนอื่น ๆ กำลังตามกันทัน

หากเป้าหมายของคุณคือการประมวลผลคำขอเดียวที่เร็วที่สุดที่เป็นไปได้ให้ดูที่มาตรฐานที่ร้ายแรงแทนการกลิ้งของคุณเอง แต่ถ้าสิ่งที่คุณต้องการเป็นเพียงสิ่งที่ปรับมาตรฐานให้เป็นภาษาที่คุณต้องการและให้แน่ใจว่าคุณไม่ได้บล็อกหัวข้อเหล่านั้น

ข้อความปฏิเสธความรับผิดชอบ: รหัสทั้งหมดและการทดสอบทำงานบน MacBook Air ในช่วงเช้าวันอาทิตย์ที่ง่วงนอน อย่าลังเลที่จะคว้ารหัสและลองใช้ Windows หรือปรับแต่งตามความต้องการของคุณ - https://github.com/csainty/nodejs-vs-aspnetcore


35
NodeJs ไม่เคยซ้ำกันเธรดต่อโมเดลขอมีอยู่ใน Asp.Net ก่อนที่ nodejs จะถูกนำเสนอวิธีการทั้งหมดที่ I / O มี 2 รุ่นซิงโครนัสและ Asynchronous ที่จัดทำโดย Framework ซึ่งเป็นวิธี ASYNC ที่ลงท้ายด้วยคีย์เวิร์ด "Async" สำหรับ เช่น. methodNameAsync
Vipresh

ในฐานะที่เป็นเช่น คุณสามารถอ้างถึงบทความนี้ที่เกี่ยวข้องกับการดำเนินงานฐานข้อมูลย้อนหลังไปถึง 2008 codedigest.com/Articles/ADO/ …
17:53 น

4
"แนวทางที่พวกเขายึดถือเป็นหลัก" - มีบางสิ่งที่ไม่เหมือนใครพวกเขาวางประเด็นต่อหน้าผู้ชมที่กว้างขึ้น การมีวิธีการที่พร้อมใช้งานและการอบเป็นหลักการหลักนั้นเป็นสองสิ่งที่แตกต่างกันมาก
Chris Sainty

4
คำตอบที่ดีที่สุดที่นี่ ระยะเวลา
Narvalex

3
@LeeBrindley ฉันไม่เห็นด้วยนี่ไม่ได้แสดงให้เห็นถึงปริมาณงานสูงสุดของฮาร์ดแวร์ที่กำหนด แต่มันแสดงให้เห็นถึงความแตกต่างระหว่างการบล็อกและการไม่บล็อก หากคุณต้องการเปรียบเทียบทรูพุตแบบดิบฉันเชื่อมโยงไปยัง techempower
Chris Sainty

14

Node Frameworks 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 นั้นสำคัญมาก!


5
ตัวเลขนี้มีไว้เพื่ออะไร? สูงกว่าดีกว่า
Iamisti
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.