ASP.NET कोर प्रदर्शन परीक्षण बनाम नोड.जेएस का अप्रत्याशित परिणाम


177

मैं दो (थोड़े) हैलो वर्ल्ड प्रोजेक्ट्स में लिखा गया एक त्वरित तनाव परीक्षण कर रहा हूं तथा । वे दोनों प्रोडक्शन मोड में चल रहे हैं और उनके बिना एक लकड़हारा जुड़ा हुआ है। परिणाम आश्चर्यजनक है! ASP.NET कोर कुछ अतिरिक्त कार्य करने के बाद भी नोड.जेएस ऐप को बेहतर बना रहा है जबकि नोड.जेएस ऐप केवल एक दृश्य प्रदान कर रहा है।

ऐप 1: http://localhost:3000/nodejs node.js

का उपयोग करना : node.js, एक्सप्रेस और वश रेंडरिंग इंजन।

नोडज एप्लिकेशन

इस समापन बिंदु में कोड है

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 पैराग्राफ उत्पन्न करता है। यह सैद्धांतिक रूप से नोडज एप्लिकेशन की तुलना में इसे थोड़ा भारी बनाना चाहिए।

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 ऐप तनाव परीक्षण परिणाम

अपडेट: गोर्गी कोसेव के सुझाव के बाद

का उपयोग करते हुए npm install -g recluster-cli && NODE_ENV=production recluster-cli app.js 8

नोडज परीक्षण २

ASP.NET कोर ऐप तनाव परीक्षण का परिणाम है

asp.net कोर तनाव परीक्षा परिणाम

मेरी आँखों पर विश्वास नहीं कर सकता! यह सच नहीं हो सकता है कि इस मूल परीक्षण में asp.net कोर नोड्ज की तुलना में अधिक तेज़ है। बेशक यह इन दो वेब प्रौद्योगिकियों के बीच प्रदर्शन को मापने के लिए उपयोग किया जाने वाला एकमात्र मीट्रिक नहीं है, लेकिन मैं सोच रहा हूं कि मैं नोड.जेएस साइड में क्या गलत कर रहा हूं?

एक पेशेवर asp.net डेवलपर होने के नाते और व्यक्तिगत परियोजनाओं में नोड.जेएस को अनुकूलित करने की इच्छा रखते हुए, यह मुझे बंद करने का एक प्रकार है - जैसा कि मैं प्रदर्शन के बारे में थोड़ा पागल हूं। मैंने सोचा था कि नोड.जेएस asp.net कोर (सामान्य रूप से - विभिन्न अन्य बेंचमार्क में देखा जाता है) की तुलना में तेज़ है। मैं इसे केवल खुद को साबित करना चाहता हूं (नोड को समायोजित करने के लिए प्रोत्साहित करना। js)।

कृपया टिप्पणी में उत्तर दें यदि आप चाहते हैं कि मैं अधिक कोड स्निपेट शामिल करूं।

अद्यतन: .NET कोर ऐप का समय वितरण

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
"मैंने हमेशा सोचा था कि नोड.जेएस asp.net कोर से तेज है" - मैं उत्सुक हूं कि आप ऐसा क्यों सोचते हैं? मैंने ऐसा कोई भी बेंचमार्क नहीं देखा है जो इस बात का समर्थन करता हो (नोड-जेएस को अपनाने के लिए मैंने जो मुख्य कारण सुने हैं, वे "उपयोग में आसानी" और "तेज विकास / पुनरावृत्ति समय" थे)
अनहेल्दीशीप

7
@UnholySheep यह वह सब है जो मैंने दोस्त को सुना, मैंने यह भी सुना है कि "इसका उपयोग करना आसान है" और "तेजी से विकसित करने के लिए" भी, आम तौर पर लोगों द्वारा उपयोग किए जाने वाले ASP.NET में कभी भी काम नहीं किया जाता है, खासकर विज़ुअलस्टडियो में। मैं किसी भी प्रौद्योगिकी के बारे में डींग नहीं मार रहा हूं - लेकिन यह वह पैटर्न है जिसे मैंने देखा है।
अपरिभाषित

3
यहाँ सवाल क्या है? यदि यह प्रशंसनीय है: हाँ यह है। techempower.com/benchmark/… .... अपने टूलचैन को भी अपडेट करें Dnxcore50 कम से कम एक या दो साल से पुराना है।
थॉमस

2
@ क्लस्टर मॉड्यूल का उपयोग कर NodeJs कर रहे कई श्रमिकों को पैदा करता है और मुख्य प्रक्रिया का लोड साझा करता है जो एकल प्रक्रिया पर सुन रहा है। यह सिर्फ विभिन्न बंदरगाहों पर कई अनुप्रयोग स्थापित करने से बचा जाता है। इसके अलावा अगर नोडज क्लस्टर मोड में चल रहा है, तो आईआईएस में अलग-अलग पोर्ट पर चलने वाले Asp.Net WebApplications की समान संख्या होनी चाहिए और कुछ लोड बैलेंसर के माध्यम से उनके बीच लोड साझा करना चाहिए, तो यह सही तुलना होगी।
विप्रेश

36
Node.js बहुत सी चीजों के लिए महान है, लेकिन प्रति अनुरोध कच्ची गति उनमें से एक नहीं है। गैर-अवरोधक ईवेंट-लूप चीज़ के कारण, आई / ओ संचालन के लिए ब्रोकर होने के नाते यह एक्सेल है, जो कि, जब नोड नया और चमकदार था, तो यह एक बड़ी बात थी। बेशक, तब से अन्य भाषाओं और रूपरेखाओं ने पकड़ लिया है, इसलिए .NET में हमारे पास टास्क समानांतर लाइब्रेरी और एसिंक्रोनस I / O और async / प्रतीक्षा है। एनओडी किस पर उत्कृष्टता प्राप्त नहीं करता है, यह सीपीयू-बाउंड ऑपरेशन जैसे पेज रेंडरिंग है, क्योंकि यह एकल-थ्रेडेड जावास्क्रिप्ट है।
मार्क रेंडले

जवाबों:


188

जैसा कि कई अन्य लोगों ने कहा है, तुलना में संदर्भ का अभाव है।
इसके जारी होने के समय, नोड.जेएस का एसिंक्रियस दृष्टिकोण क्रांतिकारी था। तब से अन्य भाषाएं और वेब फ्रेमवर्क उन तरीकों को अपना रहे हैं जिन्हें उन्होंने मुख्यधारा में लिया था।

यह समझने के लिए कि अंतर का क्या मतलब है, आपको एक अवरुद्ध अनुरोध को अनुकरण करने की आवश्यकता है जो कुछ IO कार्यभार का प्रतिनिधित्व करता है, जैसे कि डेटाबेस अनुरोध। थ्रेड-प्रति-अनुरोध प्रणाली में, यह थ्रेडपूल को समाप्त कर देगा और उपलब्ध थ्रेड के इंतजार में नए अनुरोध कतार में लग जाएंगे।
गैर-अवरुद्ध-io ढांचे के साथ ऐसा नहीं होता है।

प्रतिक्रिया देने से पहले 1 सेकंड प्रतीक्षा करने वाले इस नोड.जेएस सर्वर पर विचार करें

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 / wait को अभी तक समर्थित नहीं किया गया है, इसलिए हमें वापस नोड में वापस भेज दिया गया है। लॉन्च का युग।

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! यहां हम थ्रेडपूल की सीमा देखते हैं। इसे ट्यून करके हम अधिक समवर्ती अनुरोध प्राप्त कर सकते हैं, लेकिन अधिक सर्वर संसाधनों की कीमत पर।

इन आईओ-बाउंड वर्कलोड के लिए, प्रसंस्करण थ्रेड्स को अवरुद्ध करने से बचने का कदम नाटकीय था।

अब इसे आज के लिए लाते हैं, जहां उस प्रभाव को उद्योग के माध्यम से काट दिया गया है और डॉटनेट को इसके सुधारों का लाभ उठाने की अनुमति देता है।

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

यहाँ कोई आश्चर्य नहीं, हम अब नोड से मेल खाते हैं।

तो इन सब का क्या अर्थ है?

आपका इंप्रेशन कि नोड.जेएस "सबसे तेज़" है, एक ऐसे युग से आता है जिसमें हम अब नहीं रह रहे हैं। यह जोड़ें कि यह कभी भी नोड / जेएस / वी 8 नहीं था जो "तेज" थे, यह था कि उन्होंने थ्रेड-प्रति-अनुरोध को तोड़ दिया था नमूना। बाकी सब लोग झेल रहे हैं।

यदि आपका लक्ष्य एकल अनुरोधों का सबसे तेज़ संभव प्रसंस्करण है, तो अपने स्वयं के रोल करने के बजाय गंभीर बेंचमार्क देखें । लेकिन अगर इसके बजाय आप चाहते हैं कि बस कुछ ऐसा है जो आधुनिक मानकों के अनुरूप है, तो आप जिस भी भाषा को पसंद करते हैं, उसके लिए जाएं और सुनिश्चित करें कि आप उन थ्रेड्स को ब्लॉक नहीं कर रहे हैं।

अस्वीकरण: सभी कोड लिखे गए, और परीक्षण एक बूढ़े मैकबुक एयर पर रविवार की सुबह नींद के दौरान चलते हैं। बेझिझक कोड को पकड़ो और विंडोज पर इसे आज़माएं या अपनी आवश्यकताओं के लिए ट्वीक करें - https://github.com/csainty/nodejs-vs-aspnetcore


35
NodeJs कभी भी अद्वितीय नहीं थे, नोड प्रतिवेदन से पहले थ्रेड प्रति अनुरोध मॉडल भी मौजूद था। नोड में शामिल होने से पहले I / O के जो भी तरीके थे, फ्रेमवर्क द्वारा प्रदान किए गए 2 संस्करण तुल्यकालिक और अतुल्यकालिक थे, उनके ASYNC तरीके कीवर्ड "Async" के लिए थे। जैसे। methodNameAsync
विप्रेष

एक उदाहरण के रूप में। यू के लिए 2008 वापस डेटिंग डीबी संचालन से संबंधित इस लेख का उल्लेख कर सकते codedigest.com/Articles/ADO/...
Vipresh

4
"उन्होंने जिन तरीकों को मुख्यधारा में लिया" - कुछ चीजें अद्वितीय हैं, उन्होंने इस मुद्दे को बहुत व्यापक दर्शकों के सामने रखा। एक दृष्टिकोण उपलब्ध होने, और इसे एक मूल सिद्धांत के रूप में बेक किया जाना दो अलग चीजें हैं।
क्रिस सैंटी

4
यहाँ सबसे अच्छा जवाब। अवधि।
नरवालेक्स

3
@LeeBrindley मैं असहमत हूं, यह दिए गए हार्डवेयर के अधिकतम प्रवाह को प्रदर्शित करने की कोशिश नहीं कर रहा है, यह अवरुद्ध और गैर-अवरुद्ध के बीच के अंतर को प्रदर्शित कर रहा है। यदि आप कच्चे थ्रूपुट की तुलना करना चाहते हैं तो मैं techempower से जुड़ता हूं।
क्रिस सैंटी

14

एक्सप्रेस और कोआ जैसे नोड फ्रेमवर्क में एक भयानक ओवरहेड है। "रॉ" नोड काफी तेज है।

मैंने इसकी कोशिश नहीं की है, लेकिन एक नया ढांचा है जो "रॉ" नोड प्रदर्शन के बहुत करीब है: 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

जैसा कि आप देख सकते हैं, सबसे लोकप्रिय नोड.जेएस चौखटे में ओवरहेड बहुत महत्वपूर्ण हैं!


5
के लिए संख्या क्या हैं? बेहतर बेहतर?
Iamisti
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.