सवाल नोड.जेएस बनाम नेट प्रदर्शन


मैंने नोड.जेएस के बारे में काफी कुछ पढ़ा है और बड़ी मात्रा में लोड को समायोजित करने में सक्षम है। क्या किसी के पास इस बनाम अन्य ढांचे के वास्तविक दुनिया सबूत हैं, खासकर .Net? मैंने जो लेख पढ़े हैं, वे अचूक हैं या नेट की तुलना नहीं है।

धन्यवाद


163
2018-02-15 08:40


मूल


क्या आप किस तरह के परिदृश्य में बात कर रहे हैं में आप अधिक सटीक हो सकते हैं? - Marcus Granström
आईआईएस में चल रहे तुलनीय वेब अनुप्रयोगों के लिए मुझे .NET और Node.js की किसी भी प्रदर्शन तुलना में रूचि है। - David Merrilees
मैं कल्पना नहीं कर सकता कि कोई भी ऐसी वेबसाइट बना रहा है जिसमें उच्च perf था। नेट से बाहर की आवश्यकताएं आपके द्वारा चलाए जाने वाली सबसे बुनियादी समस्या यह है कि यह उच्च perf के बाद लाइसेंसिंग के मामले में बहुत ही लागत प्रभावी नहीं होगा। साइटों को आमतौर पर स्केलिंग की आवश्यकता होती है। और नहीं, मैं नेट नफरत नहीं हूं। नेट बिलों का भुगतान करता है। - Shane Courtrille
मुझे नोड / एक्सप्रेस / मोंगो और नए नेट नेटपी / मोंगो का उपयोग करके एक छोटे आरईएसटी एपीआई के आंतरिक परीक्षण करना पड़ा और क्लाइंट की इच्छा के आधार पर परफ अंतर थे, लेकिन दिन के अंत में, पर्याप्त बनाने के लिए पर्याप्त नहीं था अंतर। आपको अपने स्वयं के परिदृश्यों के आधार पर अपने स्वयं के परीक्षण विकसित करने की आवश्यकता है। हमें दोनों भाषाओं में अलग-अलग एपीआई लिखने के लिए तीन दिन लग गए और फिर परीक्षण के ठीक से सेटअप करने के लिए कुछ और दिन लगे। यदि आप कुछ भी गंभीर रूप से गंभीर करने की योजना बना रहे हैं, तो मैं आपकी आवश्यकताओं के आधार पर परीक्षण स्थापित करने का सुझाव दूंगा और अपने आप के लिए निर्णय लेगा जो आपके लोड के लिए बेहतर है। - AlexGad
@ShaneCourtrille आप भ्रमित हैं। नेट (एक ढांचा) और विंडोज (एक ऑपरेटिंग सिस्टम)। वे बहुत अलग चीजें हैं और नेट के लिए कोई लाइसेंसिंग आवश्यकता नहीं है (जो लिनक्स पर मोनो के रूप में काफी अच्छी तरह से चलती है)। - rainabba


जवाब:


होने के नाते फास्ट और बहुत से हैंडलिंग भार दो अलग-अलग चीजें हैं। एक सर्वर जो वास्तव में है फास्ट प्रति सेकंड एक अनुरोध की सेवा करने पर पूरी तरह से क्रोक हो सकता है यदि आप प्रति सेकंड 500 अनुरोध भेजते हैं (नीचे भार)।

आपको स्थिर (और कैश) बनाम गतिशील पृष्ठों पर भी विचार करना होगा। यदि आप स्थैतिक पृष्ठों के बारे में चिंतित हैं, तो आईआईएस शायद नोड को हरा करने जा रहा है क्योंकि आईआईएस कर्नेल-मोड कैशिंग का उपयोग करता है, जिसका अर्थ यह है कि एक स्थिर पृष्ठ का अनुरोध करने वाले अनुरोध कर्नेल से बाहर नहीं जा रहे हैं।

मुझे लगता है कि आप एएसपी.नेट और नोड के बीच तुलना की तलाश में हैं। इस लड़ाई में, सबकुछ संकलित / व्याख्या किए जाने के बाद आप शायद प्रदर्शन में बहुत करीब रहेंगे। शायद .NET थोड़ा है और तेज या शायद नोड थोड़ा है और तेज, लेकिन शायद यह काफी करीब है कि आपको परवाह नहीं है। मैं .NET पर शर्त लगाऊंगा, लेकिन मुझे यकीन नहीं है।

नोड जो जगह वास्तव में आकर्षक है वह हैडलिंग के लिए है भार। यह वह जगह है जहां प्रौद्योगिकियां वास्तव में भिन्न होती हैं। एएसपी.नेट प्रत्येक थ्रेड पूल से प्रत्येक अनुरोध के लिए धागा समर्पित करता है, और एक बार एएसपी.नेट समाप्त हो जाने के बाद सभी उपलब्ध थ्रेड अनुरोधों को कतारबद्ध करना शुरू हो जाता है। यदि आप "हैलो वर्ल्ड" ऐप्स की सेवा कर रहे हैं जैसे कि @ शंकर द्वारा उदाहरण, तो इससे कोई फर्क नहीं पड़ता क्योंकि धागे अवरुद्ध नहीं होने जा रहे हैं और आप अपने सामने कई अनुरोधों को संभालने में सक्षम होंगे धागे से बाहर भागो। एएसपी.नेट मॉडल के साथ समस्या तब आती है जब आप I / O अनुरोधों को प्रारंभ करना शुरू करते हैं जो थ्रेड को अवरुद्ध करते हैं (डीबी पर कॉल करें, किसी सेवा के लिए http अनुरोध करें, डिस्क से फ़ाइल पढ़ें)। इन अवरुद्ध अनुरोधों का मतलब है कि थ्रेड पूल से आपका मूल्यवान धागा कुछ भी नहीं कर रहा है। जितना अधिक अवरुद्ध हो उतना कम भार आपका एएसपी.नेट ऐप सेवा करने में सक्षम होने जा रहा है।

इस अवरोध को रोकने के लिए, आप I / O समापन बंदरगाहों का उपयोग करते हैं जिन्हें प्रतिक्रिया के लिए प्रतीक्षा करते समय थ्रेड रखने की आवश्यकता नहीं होती है। एएसपी.नेट इसका समर्थन करता है, लेकिन दुर्भाग्य से .NET में सामान्य फ्रेमवर्क / पुस्तकालयों में से कई नहीं हैं। उदाहरण के लिए, एडीओ.NET I / O समापन बंदरगाहों का समर्थन करता है, लेकिन इकाई फ्रेमवर्क उनका उपयोग नहीं करता है। तो आप एक एएसपी.NET ऐप बना सकते हैं जो पूरी तरह से असीमित है और बहुत सारे भार को संभालता है, लेकिन ज्यादातर लोग ऐसा नहीं करते हैं क्योंकि यह सिंक्रोनस के निर्माण के जितना आसान नहीं है, और हो सकता है कि आप अपने कुछ पसंदीदा हिस्सों का उपयोग न कर सकें ढांचे के (जैसे linq से इकाइयों) यदि आप करते हैं।

समस्या यह है कि ASP.NET (और .NET Framework) को एसिंक्रोनस I / O के बारे में गैर-राय के लिए बनाया गया था। यदि आप सिंक्रोनस या एसिंक्रोनस कोड लिखते हैं तो .NET परवाह नहीं है, इसलिए यह निर्णय लेने के लिए डेवलपर पर निर्भर है। इसका एक हिस्सा इसलिए है क्योंकि एसिंक्रोनस ऑपरेशंस के साथ थ्रेडिंग और प्रोग्रामिंग को "कड़ी" माना जाता था, और .NET सभी को खुश करना चाहता था (नोब और विशेषज्ञ)। यह और भी कठिन हो गया क्योंकि .NET एसिंक करने के लिए 3-4 विभिन्न पैटर्न के साथ समाप्त हुआ। .NET 4.5 वापस जाने और .NET Framework को एसिंक आईओ के आस-पास एक राय मॉडल रखने के लिए पुनः प्रयास कर रहा है, लेकिन यह थोड़ी देर तक हो सकता है जब तक कि आप वास्तव में इसका समर्थन करने वाले ढांचे के बारे में सोचें।

दूसरी ओर नोड के डिजाइनरों ने एक राय की पसंद की कि सभी I / O async होना चाहिए। इस फैसले के कारण, नोड डिज़ाइनर निर्णय लेने में भी सक्षम थे कि नोड के प्रत्येक इंस्टेंस को थ्रेड स्विचिंग को कम करने के लिए सिंगल थ्रेडेड किया जाएगा, और एक थ्रेड कतारबद्ध कोड को निष्पादित करेगा। यह एक नया अनुरोध हो सकता है, यह डीबी अनुरोध से कॉलबैक हो सकता है, यह आपके द्वारा किए गए http आराम अनुरोध से कॉलबैक हो सकता है। नोड थ्रेड संदर्भ स्विच को समाप्त करके सीपीयू दक्षता को अधिकतम करने की कोशिश करता है। चूंकि नोड ने इस विचार की पसंद की कि सभी I / O असीमित है, इसका भी अर्थ है कि यह सभी ढांचे / ऐड-ऑन इस विकल्प का समर्थन करते हैं। उन ऐप्स को लिखना आसान है जो नोड में 100% async हैं (क्योंकि नोड आपको एसिंक के ऐप्स लिखने के लिए मजबूर करता है)।

दोबारा, मेरे पास एक या दूसरे तरीके से साबित करने के लिए कोई कठोर संख्या नहीं है, लेकिन मुझे लगता है कि नोड सामान्य वेब ऐप के लिए लोड प्रतियोगिता जीत जाएगा। एक अत्यधिक अनुकूलित (100% async) .NET ऐप समकक्ष node.js ऐप को इसके पैसे के लिए एक रन दे सकता है, लेकिन यदि आपने वहां सभी .NET और सभी नोड ऐप्स का औसत लिया है, तो औसत नोड शायद अधिक संभालता है भार।

उम्मीद है की वो मदद करदे।


352
2018-06-16 01:36



याद रखें कि एएसपी.नेट ने लंबे समय तक एसिंक अनुरोध हैंडलर का समर्थन किया है, और एमवीसी 4 के साथ वे उपयोग करने के लिए बेहद सरल हो गए हैं। - fabspro
"इन अवरुद्ध अनुरोधों का मतलब है कि थ्रेड पूल से आपका मूल्यवान धागा कुछ भी नहीं कर रहा है। आपके पास जितना अधिक अवरोध है, उतना ही कम आपका एएसपी.नेट ऐप सेवा करने में सक्षम होगा।"   इससे कोई फर्क क्यों पड़ता है कि हम आगे (आने वाले अनुरोध) या बैकएंड (वास्तविक कार्य धागा) में कतारबद्ध हैं? कोई फर्क नहीं पड़ता कि, ग्राहक अनुरोध प्रतिक्रिया के लिए इंतजार कर रहा है। मुझे लगता है कि इस बहस में लोगों को अनदेखा करने वाली कुंजी "थ्रूपुट" है। यह सर्वर के कितने समवर्ती कनेक्शन के बारे में नहीं है, यह कितनी तेज़ी से प्रत्येक अनुरोध का जवाब दे सकता है? - sjdirect
// मुझे मेरी टिप्पणी संपादित करने नहीं देगा, इसलिए मैं यही कहने का मतलब रखता हूं .// @sjdirect - थ्रूपुट प्रतिक्रिया समय के समान नहीं है। आपको प्रतिक्रिया समय के बारे में परवाह करने का अधिकार है, लेकिन यह कतार समय + प्रतिक्रिया समय, या केवल प्रतिक्रिया समय के बीच एक विकल्प है। अनुरोध की प्रक्रिया दोनों परिदृश्यों में जितनी देर तक चल रही है (सिंक्रनाइज़ेशन निष्पादित करना आपके डीबी अनुरोध को किसी भी तेज़ी से निष्पादित नहीं करेगा), लेकिन यदि आपके अनुरोध धागे अवरुद्ध हैं, तो आप अनुरोधों के लिए कतार समय जोड़ रहे हैं क्योंकि आप अनुरोधों को तब तक संसाधित करना शुरू नहीं कर सकते जब तक कि पिछले अनुरोध नहीं किए जाते। - Matt Dotson
यह वास्तव में जानकारीपूर्ण था, धन्यवाद! ध्यान देने योग्य एक बात यह है कि एंटीटी फ्रेमवर्क 6 (वर्तमान में आरसी 1) अब .NET 4.5 से एसिंक्रोनस पैटर्न का समर्थन करता है। msdn.microsoft.com/en-us/data/jj819165 - parliament
यह बेहद सट्टा है! डेटा होना बहुत अच्छा होगा। आम तौर पर मैं कैसे निर्णय लेता हूं कि प्रदर्शन के विषयों के साथ कैसे आगे बढ़ना है। - kingPuppy


मैंने नोडज और आईआईएस के बीच एक प्राथमिक प्रदर्शन परीक्षण किया। "हैलो, दुनिया!" बाहर निकलने पर आईआईएस नोडज से 2.5 गुना तेज है। नीचे कोड

मेरा हार्डवेयर: डेल अक्षांश E6510, कोर i5 (दोहरी कोर), 8 जीबी रैम, विंडोज 7 एंटरप्राइज़ 64 बिट ओएस

नोड सर्वर

runs at http://localhost:9090/
/// <reference path="node-vsdoc.js" />
var http = require("http");
http.createServer(function (request, response) {
response.writeHead(200, { "Content-Type": "text/html" });
response.write("<p>hello, world!</p>");
response.end();
}).listen(9090);

default.htm

hosted by iis at http://localhost/test/
<p>hello, world!</p>

कार्य समांतर पुस्तकालय का उपयोग कर अपना स्वयं का बेंचमार्क प्रोग्राम:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Net;
using System.Threading;
using System.Threading.Tasks;
using System.Diagnostics;

namespace HttpBench
{
class Program
{
    private int TotalCount = 100000;
    private int ConcurrentThreads = 1000;
    private int failedCount;
    private int totalBytes;
    private int totalTime;
    private int completedCount;
    private static object lockObj = new object();

    /// <summary>
    /// main entry point
    /// </summary>
    static void Main(string[] args)
    {
        Program p = new Program();
        p.Run(args);
    }

    /// <summary>
    /// actual execution
    /// </summary>
    private void Run(string[] args)
    {
        // check command line
        if (args.Length == 0)
        {
            this.PrintUsage();
            return;
        }
        if (args[0] == "/?" || args[0] == "/h")
        {
            this.PrintUsage();
            return;
        }

        // use parallel library, download data
        ParallelOptions options = new ParallelOptions();
        options.MaxDegreeOfParallelism = this.ConcurrentThreads;
        int start = Environment.TickCount;
        Parallel.For(0, this.TotalCount, options, i =>
            {
                this.DownloadUrl(i, args[0]);
            }
        );
        int end = Environment.TickCount;

        // print results
        this.Print("Total requests sent: {0}", true, this.TotalCount);
        this.Print("Concurrent threads: {0}", true, this.ConcurrentThreads);
        this.Print("Total completed requests: {0}", true, this.completedCount);
        this.Print("Failed requests: {0}", true, this.failedCount);
        this.Print("Sum total of thread times (seconds): {0}", true, this.totalTime / 1000);
        this.Print("Total time taken by this program (seconds): {0}", true, (end - start) / 1000);
        this.Print("Total bytes: {0}", true, this.totalBytes);
    }

    /// <summary>
    /// download data from the given url
    /// </summary>
    private void DownloadUrl(int index, string url)
    {
        using (WebClient client = new WebClient())
        {
            try
            {
                int start = Environment.TickCount;
                byte[] data = client.DownloadData(url);
                int end = Environment.TickCount;
                lock (lockObj)
                {
                    this.totalTime = this.totalTime + (end - start);
                    if (data != null)
                    {
                        this.totalBytes = this.totalBytes + data.Length;
                    }
                }
            }
            catch
            {
                lock (lockObj) { this.failedCount++; }
            }
            lock (lockObj)
            {
                this.completedCount++;
                if (this.completedCount % 10000 == 0)
                {
                    this.Print("Completed {0} requests.", true, this.completedCount);
                }
            }
        }
    }

    /// <summary>
    /// print usage of this program
    /// </summary>
    private void PrintUsage()
    {
        this.Print("usage: httpbench [options] <url>");
    }

    /// <summary>
    /// print exception message to console
    /// </summary>
    private void PrintError(string msg, Exception ex = null, params object[] args)
    {
        StringBuilder sb = new System.Text.StringBuilder();
        sb.Append("Error: ");
        sb.AppendFormat(msg, args);
        if (ex != null)
        {
            sb.Append("Exception: ");
            sb.Append(ex.Message);
        }
        this.Print(sb.ToString());
    }

    /// <summary>
    /// print to console
    /// </summary>
    private void Print(string msg, bool isLine = true, params object[] args)
    {
        if (isLine)
        {
            Console.WriteLine(msg, args);
        }
        else
        {
            Console.Write(msg, args);
        }
    }

}
}

और परिणाम:

IIS: httpbench.exe http://localhost/test

Completed 10000 requests.
Completed 20000 requests.
Completed 30000 requests.
Completed 40000 requests.
Completed 50000 requests.
Completed 60000 requests.
Completed 70000 requests.
Completed 80000 requests.
Completed 90000 requests.
Completed 100000 requests.
Total requests sent: 100000
Concurrent threads: 1000
Total completed requests: 100000
Failed requests: 0
Sum total of thread times (seconds): 97
Total time taken by this program (seconds): 16
Total bytes: 2000000

nodejs: httpbench.exe http://localhost:9090/

Completed 10000 requests.
Completed 20000 requests.
Completed 30000 requests.
Completed 40000 requests.
Completed 50000 requests.
Completed 60000 requests.
Completed 70000 requests.
Completed 80000 requests.
Completed 90000 requests.
Completed 100000 requests.
Total requests sent: 100000
Concurrent threads: 1000
Total completed requests: 100000
Failed requests: 0
Sum total of thread times (seconds): 234
Total time taken by this program (seconds): 27
Total bytes: 2000000

निष्कर्ष: आईआईएस नोडजेज़ से लगभग 2.5 गुना (विंडोज़ पर) से तेज है। यह एक बहुत ही प्राथमिक परीक्षा है, और किसी भी तरह से निर्णायक नहीं है। लेकिन मेरा मानना ​​है कि यह एक अच्छा प्रारंभिक बिंदु है। नोडजेस अन्य वेब सर्वरों पर अन्य प्लेटफार्मों पर शायद तेज़ है, लेकिन विंडोज आईआईएस विजेता है। डेवलपर्स अपने एएसपी.नेट एमवीसी को नोडजेज़ में कनवर्ट करना चाहते हैं, आगे बढ़ने से पहले दो बार रोकें और सोचें।

अपडेट किया गया (5/17/2012) टॉमकैट (विंडोज़ पर) आईआईएस हाथों को हराकर लगता है, स्थिर एचटीएमएल को खत्म करने में आईआईएस की तुलना में लगभग 3 गुना तेजी से।

बिल्ला

index.html at http://localhost:8080/test/
<p>hello, world!</p>

टॉमकैट परिणाम

httpbench.exe http://localhost:8080/test/
Completed 10000 requests.
Completed 20000 requests.
Completed 30000 requests.
Completed 40000 requests.
Completed 50000 requests.
Completed 60000 requests.
Completed 70000 requests.
Completed 80000 requests.
Completed 90000 requests.
Completed 100000 requests.
Total requests sent: 100000
Concurrent threads: 1000
Total completed requests: 100000
Failed requests: 0
Sum total of thread times (seconds): 31
Total time taken by this program (seconds): 5
Total bytes: 2000000

अद्यतन निष्कर्ष: मैंने कई बार बेंचमार्क कार्यक्रम चलाया। टॉमकैट स्टेटिक एचटीएमएल को खत्म करने में सबसे तेज़ सर्वर प्रतीत होता है, विंडोज़ पर।

अपडेट किया गया (5/18/2012) पहले मेरे पास 10,000 समवर्ती अनुरोधों के साथ 100,000 कुल अनुरोध थे। मैंने इसे 1,000,000 कुल आवश्यकता और 100,000 समवर्ती अनुरोधों में बढ़ा दिया। आईआईएस चिल्लाने वाले विजेता के रूप में बाहर आता है, जिसमें नोडज सबसे बुरी स्थिति में हैं। मैंने नीचे दिए गए परिणामों को सारणीबद्ध किया है:

NodeJS vs IIS vs Tomcat serving STATIC HTML on WINDOWS


47
2018-05-17 18:24



आप बिल्लियों के साथ सेब की तुलना कर रहे हैं। एएसपी.नेट एमवीसी के साथ नोड.जेएस की तुलना करें। अधिकांश आईआईएस स्थिर फाइलों की सेवा करने में तेज़ है, हालांकि मुझे गंभीरता से संदेह है। - alessioalex
@alessioalex: मुझे समझ में नहीं आता कि यह तुलना मान्य क्यों नहीं है। मैं स्थिर एचटीएमएल के लिए प्रतिक्रिया समय की तुलना कर रहा हूँ। आईआईएस डिफ़ॉल्ट एचटीएमएल से स्थिर एचटीएमएल निकाल रहा है, जबकि नोडजेस सर्वर एक ही स्ट्रिंग को खत्म कर रहा है, और आईआईएस आगे आता है। एएसपी.नेट एमवीसी अनुप्रयोग की तुलना में अधिक प्रयास और समय की आवश्यकता होगी, और मैं इसे बाद में करने की योजना बना रहा हूं। - Shankar
ठीक है, कहें कि आईआईएस विंडोज़ पर नोड की तुलना में स्थिर फाइलों की सेवा करने में बेहतर है। आईआईएस केवल स्थैतिक फाइलों और जैसे (अपाचे या एनजीआईएनएक्स) की सेवा करता है, नोड उससे कहीं अधिक करता है। आपको नोड के साथ एएसपी.नेट एमवीसी की तुलना करनी चाहिए (डेटाबेस से पूछताछ करना, बाहरी सेवा से डेटा पुनर्प्राप्त करना आदि)। आपको एएसपी.नेट एमवीसी पर नोड के साथ भारी प्रदर्शन लाभ दिखाई देगा। - alessioalex
यदि आप ऐसा करने जा रहे हैं, तो कृपया कम से कम नोड की प्रकृति को समझें। एक नोड प्रक्रिया केवल एक कोर का उपयोग कर सकते हैं। तो, आप जो तुलना कर रहे हैं वह एक कोर पर एक कोर पर चलने वाली नोड प्रक्रिया है और एकाधिक कोर का उपयोग करके टॉमकैट प्रक्रिया है। सही ढंग से तुलना करने के लिए, आपको नोड क्लस्टर चलाने की आवश्यकता है। देख nodejs.org/api/cluster.html क्लस्टर समाधान का उपयोग करने के लिए एक सरल के लिए। हालांकि, मैं आपको अनुभव से बता सकता हूं, जो भी आप कर रहे हैं उसके आधार पर नोड और एसिंक सी # के बीच का अंतर 10-15% है। - AlexGad
इसके अलावा, नोड और आईआईएस और टोमकैट के साथ स्थैतिक फाइलों का परीक्षण अर्थहीन है। सबसे पहले, स्थिर फाइलों के लिए नोड बहुत अच्छा नहीं है, लेकिन इसका वास्तव में मतलब नहीं है (सही नौकरी के लिए सही उपकरण का उपयोग करें)। अगर कोई अपनी स्थिर फाइलों की गति के बारे में चिंतित है, तो उन्हें किसी भी तरह से सीडीएन का उपयोग करना चाहिए। - AlexGad


मुझे मार्कस ग्रैनस्ट्रॉम से सहमत होना है, परिदृश्य यहां बहुत महत्वपूर्ण है।

ईमानदार होने के लिए ऐसा लगता है कि आप उच्च प्रभाव वाले वास्तुशिल्प निर्णय ले रहे हैं। मेरी सलाह चिंता के क्षेत्रों को अलग करना और आप जो भी ढेर पर विचार कर रहे हैं, उसके बीच "सेंकना" करना होगा।

दिन के अंत में आप निर्णय के लिए ज़िम्मेदार हैं और मुझे बहाना नहीं लगता है "स्टैक ओवरफ्लो पर कुछ लड़के ने मुझे एक लेख दिखाया जो कहा कि यह ठीक होगा" इसे अपने मालिक के साथ काट देगा।


11
2018-02-15 13:52



मैं लोगों को मनाने के लिए कुछ ढूंढ रहा हूं (मेरे बॉस समेत) एक एमवीसीनेट वेबसाइट के विकल्प के रूप में विचार करने लायक है, उन्हें मनाने के लिए हमें स्वैप करना चाहिए। जो कुछ मैंने अभी तक पाया है वह अचूक उल्लेख है कि यह अधिक भार का समर्थन कर सकता है और बेहतर प्रदर्शन कर सकता है। क्या किसी ने वास्तव में यह साबित किया है? - David Merrilees
लेकिन एमवीसी वेबसाइट के साथ क्या गलत है? आप एक विकल्प खोजने की कोशिश क्यों कर रहे हैं? यह सबसे महत्वपूर्ण प्रश्न है। यदि समस्या यह है कि यह भारी समवर्ती भार के तहत कुत्ता धीमा है, तो आपको यह सुनिश्चित करना चाहिए कि आप async.net का उपयोग कर रहे हैं। यदि यह अभी भी वास्तव में धीमा है, तो आपको अपना कोड तोड़ना होगा और पता लगाएं कि आपकी बाधाएं कहां हैं। मेरे अनुभव में, असली दुनिया परिदृश्य में नोड और एसिंक नेट के बीच एक बड़ा अंतर नहीं है। आप अपना प्लेटफॉर्म बदल सकते हैं, लेकिन आप कोड बाधाओं / सिरदर्द के दूसरे सेट के लिए बस कोड बाधाओं / सिरदर्द के एक सेट को बदल देंगे। - AlexGad


एनआईओ सर्वर (नोड.जेएस इत्यादि) बीआईओ सर्वर से तेज़ होते हैं। (आईआईएस आदि)। मेरे दावे को वापस करने के लिए, TechEmpower एक कंपनी विशेष है वेब ढांचे बेंचमार्क। वे बहुत खुले हैं और सभी फ्रेमलेखों का परीक्षण करने का एक मानक तरीका है।

दौर 9 परीक्षण वर्तमान में नवीनतम हैं (मई 2014)। कई आईआईएस स्वाद परीक्षण किए गए हैं, लेकिन एस्पनेट-स्ट्रिपेड सबसे तेज़ आईआईएस संस्करण है।

यहां परिणाम हैं प्रति सेकेंड प्रतिक्रियाएं (उच्च बेहतर है):

  • जेएसओएन सीरियलाइजेशन
    • NodeJS: 228,887
    • aspnet-छीन: 105,272
  • एकल प्रश्न
    • NodeJS-mysql: 88,597
    • aspnet-छीन कच्चे: 47,066
  • एकाधिक प्रश्नोत्तरी
    • NodeJS-mysql: 8,878
    • aspnet-छीन कच्चे: 3,915
  • सादे पाठ
    • NodeJS: 289,578
    • aspnet-छीन: 109,136

सभी मामलों में, नोड.जेएस आईआईएस की तुलना में 2x + तेज होता है।


11
2017-09-06 20:55



एकाधिक क्वेरीज़ परीक्षण को छोड़कर, जहां एएसपीएनईटी की दो प्रविष्टियां होती हैं (एस्पनेट-स्ट्रिप-कच्चा और एस्पनेट-माइस्क्ल-कच्चा) जो दोनों नोडजेस-माइस्क्ल को हराते हैं, जो शीर्ष एनजे प्रविष्टि है। - GalacticCowboy
खैर, एकाधिक क्वेरी परीक्षण बिल्कुल सर्वर की गति का परीक्षण नहीं कर रहा है। यह मुख्य रूप से MySQL ड्राइवर की गति का परीक्षण कर रहा है। नोडजेएस मुख्य रूप से मोंगो डीबी, कॉच डीबी जैसे नो-एसक्यूएल डेटाबेस का उपयोग करता है। MySQL ड्राइवर अनुकूलित नहीं किया जा सकता है। जेसन सीरियलाइजेशन और प्लेनटेक्स्ट परीक्षण शुद्ध सर्वर की गति देते हैं - मैं उन पर भरोसा करता हूं। - ttekin


मुख्य अंतर जो मैं देखता हूं वह यह है कि नोड .js गतिशील प्रोग्रामिंग भाषा (प्रकार की जांच) है, इसलिए प्रकार रन-टाइम व्युत्पन्न होने चाहिए। दृढ़ता से टाइप की गई भाषाओं जैसे सी # .NET ने सैद्धांतिक रूप से अधिक संभावनाएं नोड। जेएस (और PHP इत्यादि) के खिलाफ लड़ाई जीत ली है, खासकर महंगी गणना कहां है। जिस तरह से .NET को node .js की तुलना में सी / सी ++ के साथ बेहतर देशी इंटरऑपरेशन होना चाहिए।


1
2017-08-22 21:19



आपका सुझाव है कि जेएस में "कमजोर" टाइपिंग इसे धीमा कर देती है, गलत और अप्रासंगिक है और परवाह किए बिना, यह एप्पल और स्टोन्स की तुलना कर रही है (यहां तक ​​कि संतरे आप जो भी सुझाव दे रहे हैं उससे भी अधिक समान होंगे)। - rainabba
@rainabba जब आप किसी प्रकार की गणना की तुलना करते हैं (उदा। x की fibonacci) वह पूरी तरह से सही है। - sed
@steve वास्तव में, जेड दिया गया, आप अभी भी यह नहीं कह सकते कि जेएस एक भाषा है और नेट एक ढांचा है। वे पूरी तरह से अलग चीजें हैं। .NET रनटाइम एक विशेष प्रोसेसर आर्किटेक्चर के लिए संकलित किए जाते हैं और इसलिए आप हार्डवेयर के एक टुकड़े के लिए कोड के किसी विशेष हिस्से के प्रदर्शन को महत्वपूर्ण रूप से परिवर्तित नहीं कर सकते हैं। चूंकि वी 8 दिखाता है, जेएस को व्याख्या और निष्पादित किया जा सकता है और बहुत अलग गति हो सकती है और ऐसा लगता है कि एक दिन जेएस में लिखा गया आपका फाइबोनैकी कोड सीएसआर के माध्यम से कोड के साथ जितना तेज़ नहीं होगा (संभवतः, यह होगा और तेज)। सेब और पत्थर; जैसा मैंने कहा। - rainabba
हो सकता है कि आप सही हों, लेकिन मेरी दृष्टि में, मैं चीन में अन्य देशों को नहीं जानता, कई प्रोग्रामर जिन्हें मैंने सिर्फ ईएफ या लिंक से एसक्यूएल में साक्षात्कार दिया, इन ढांचे में महत्वपूर्ण रूप से .net का प्रदर्शन कम हो गया। - dexiang
जेएस को भी यही कहा जा सकता है। जबकि जेएस फिबोनैकी पर पकड़ रहा है, क्या आप वास्तव में सोचते हैं कि .NET रहेगा जहां यह इंतजार कर रहा है? - quanben