Wydajność Node.js a .Net

Dużo czytałem o tym, że Node.js jest szybki i jest w stanie pomieścić duże ilości obciążenia. Czy ktoś ma jakieś prawdziwe dowody na to w porównaniu do innych frameworków, szczególnie .Net? Większość artykułów, które przeczytałem, jest niepotwierdzonych lub nie ma porównań z .Net.

Dzięki

Bycie SZYBKIM i radzenie sobie z dużą ilością ŁADUNKÓW to dwie różne rzeczy. Serwer, który naprawdę SZYBKO obsługuje jedno żądanie na sekundę, może całkowicie wykrzyczeć, jeśli wyślesz mu 500 żądań na sekundę (pod LOAD ).

Musisz także wziąć pod uwagę strony statyczne (i buforowane) vs. strony dynamiczne. Jeśli martwisz się o strony statyczne, to IIS prawdopodobnie pobije węzeł, ponieważ IIS używa buforowania w trybie jądra, co oznacza, że ​​żądania, które żądają strony statycznej, nawet nie wyjdą z jądra.

Zgaduję, że szukasz porównania między ASP.NET i węzłem. W tej bitwie, po skompilowaniu / zinterpretowaniu wszystkiego, zapewne będziesz blisko wydajności. Może .NET jest trochę SZYBCIEJ, a może węzeł jest trochę SZYBCIEJ , ale prawdopodobnie jest wystarczająco blisko, żebyś się tym nie przejmował. Postawiłbym na .NET, ale nie jestem pewien.

Miejsce, w którym węzeł jest naprawdę przekonujący, to obsługa LOAD . Właśnie tam technologie naprawdę się różnią. ASP.NET poświęca wątek dla każdego żądania ze swojej puli wątków, a gdy ASP.NET wyczerpie się, wszystkie dostępne żądania wątków zaczynają się kolejkować. Jeśli obsługujesz aplikacje „Hello World”, takie jak przykład @shankar, może to nie mieć większego znaczenia, ponieważ wątki nie będą blokowane i będziesz w stanie obsłużyć wiele żądań przed Tobą zabrakło wątków. Problem z modelem ASP.NET pojawia się, gdy zaczynasz wysyłać żądania We / Wy, które blokują wątek (wywoływanie DB, wysyłanie żądania HTTP do usługi, odczytywanie pliku z dysku). Te żądania blokowania oznaczają, że Twój cenny wątek z puli wątków nic nie robi. Im więcej blokujesz,ZAŁADUJ swoją aplikację ASP.NET będzie mogła służyć.

Aby zapobiec temu blokowaniu, korzystasz z portów zakończenia we / wy, które nie wymagają trzymania wątku podczas oczekiwania na odpowiedź. ASP.NET obsługuje to, ale niestety wiele popularnych frameworków / bibliotek w .NET DON'T. Na przykład ADO.NET obsługuje porty zakończenia we / wy, ale Entity Framework ich nie używa. Możesz więc zbudować aplikację ASP.NET, która jest czysto asynchroniczna i obsługuje wiele obciążeń, ale większość ludzi tego nie robi, ponieważ nie jest to tak łatwe jak zbudowanie aplikacji synchronicznej i możesz nie być w stanie użyć niektórych swoich ulubionych części frameworka (jak linq do encji), jeśli tak zrobisz.

Problem polega na tym, że ASP.NET (i .NET Framework) zostały stworzone, aby nie wyrażać opinii na temat asynchronicznych operacji we / wy. .NET nie dba o to, czy piszesz kod synchroniczny czy asynchroniczny, więc decyzja należy do programisty. Częściowo dlatego, że wątkowanie i programowanie za pomocą operacji asynchronicznych było uważane za „trudne”, a .NET chciał, aby wszyscy byli zadowoleni (noobowie i eksperci). Stało się to jeszcze trudniejsze, ponieważ .NET skończył z 3-4 różnymi wzorcami wykonywania asynchronizacji. .NET 4.5 próbuje wrócić i zmodernizować platformę .NET, aby mieć uparty model wokół asynchronicznego We / Wy, ale może upłynąć trochę czasu, zanim frameworki, na których Ci zależy, faktycznie ją obsługują.

Z drugiej strony projektanci węzła dokonali zdecydowanego wyboru, że WSZYSTKIE I / O powinny być asynchroniczne. Z powodu tej decyzji projektanci węzłów byli również w stanie podjąć decyzję, że każda instancja węzła będzie jednowątkowa, aby zminimalizować przełączanie wątków, i że jeden wątek po prostu wykona kod, który został umieszczony w kolejce. To może być nowe żądanie, może to być wywołanie zwrotne z żądania DB, może to być wywołanie zwrotne z wysłanego żądania HTTP. Węzeł próbuje zmaksymalizować wydajność procesora poprzez wyeliminowanie przełączników kontekstowych wątków. Ponieważ węzeł dokonał tego zdecydowanego wyboru, że WSZYSTKIE we / wy są asynchroniczne, oznacza to również, że wszystkie jego frameworki / dodatki obsługują ten wybór. Łatwiej jest pisać aplikacje, które są w 100% asynchroniczne w węźle (ponieważ węzeł zmusza do pisania aplikacji, które są asynchroniczne).

Ponownie nie mam twardych liczb, które mogłyby udowodnić w ten czy inny sposób, ale myślę, że węzeł wygrałby konkurs LOAD dla typowej aplikacji internetowej. Wysoce zoptymalizowana (w 100% asynchroniczna) aplikacja .NET może dać ekwiwalent aplikacji node.js za swoje pieniądze, ale jeśli weźmiesz średnio całą platformę .NET i wszystkie aplikacje węzłowe, średnio węzeł prawdopodobnie obsługuje więcej ZAŁADUJ.

Mam nadzieję, że to pomaga.

Zrobiłem podstawowy test wydajności między nodejs i IIS. IIS jest około 2,5 razy szybszy niż nodejs, gdy rozprasza „cześć, świecie!”. kod poniżej.

mój sprzęt: Dell Latitude E6510, Core i5 (dwurdzeniowy), 8 GB RAM, 64-bitowy system operacyjny Windows 7 Enterprise

serwer węzłów

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>

mój własny program testowy wykorzystujący bibliotekę zadań równoległych:

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);
        }
    }

}
}

i wyniki:

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

wniosek: IIS jest szybszy niż nodejs około 2,5 razy (w systemie Windows). Jest to bardzo podstawowy test i w żadnym wypadku nie rozstrzygający. Ale uważam, że to dobry punkt wyjścia. Nodejs jest prawdopodobnie szybszy na innych serwerach internetowych, na innych platformach, ale na Windows IIS jest zwycięzcą. Programiści, którzy chcą przekonwertować swój ASP.NET MVC na nodejs, powinni pauzować i zastanowić się dwa razy, zanim przejdą dalej.

Zaktualizowano (17.05.2012) Tomcat (w systemie Windows) wydaje się pobijać IIS, około 3 razy szybciej niż IIS w usuwaniu statycznego HTML.

kocur

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

wyniki tomcat

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

zaktualizowany wniosek: uruchomiłem program testowy wiele razy. Tomcat wydaje się być najszybszym serwerem do usuwania STATIC HTML NA WINDOWS.

Zaktualizowano (18.05.2012) Wcześniej miałem 100 000 żądań łącznie z 10 000 równoczesnych wniosków. Zwiększyłem go do 1 000 000 całkowitego zapotrzebowania i 100 000 jednoczesnych żądań. IIS pojawia się jako krzyczący zwycięzca, a Nodejs jest najgorszy. Poniżej zestawiłem wyniki:

.

Serwery NIO (Node.js itp.) Są zwykle szybsze niż serwery BIO. (IIS itp.). Aby poprzeć moje twierdzenie, TechEmpower jest firmą specjalizującą się w testach struktur sieciowych . Są bardzo otwarte i mają standardowy sposób testowania wszystkich ramek.

Testy rundy 9 są obecnie najnowsze (maj 2014). Testowanych jest wiele odmian IIS, ale pozbawiony aspnetu wydaje się być najszybszym wariantem IIS.

Oto wyniki w odpowiedziach na sekundę (im wyższa, tym lepiej):

• Serializacja JSON
  • nodejs: 228,887
  • w paski aspnet: 105,272
• Pojedyncze zapytanie
  • nodejs-mysql: 88,597
  • aspnet-stripped-raw: 47,066
• Wiele zapytań
  • nodejs-mysql: 8,878
  • aspnet-stripped-raw: 3,915
• Zwykły tekst
  • nodejs: 289,578
  • w paski aspnet: 109,136

We wszystkich przypadkach Node.js jest 2x szybszy niż IIS.

Muszę się zgodzić z Marcusem Granstromem, scenariusz jest tutaj bardzo ważny.

Szczerze mówiąc, brzmi to tak, jakbyś podejmował decyzję architektoniczną o dużym wpływie. Moją radą byłoby wyodrębnienie obszarów budzących obawy i „odpalenie” między stosami, które rozważasz.

Pod koniec dnia jesteś odpowiedzialny za decyzję i nie sądzę, żeby wymówka „Jakiś facet na Stackoverflow pokazał mi artykuł, który powiedziałby, że będzie w porządku” Obetnie to swojemu szefowi.

Główną różnicą, którą widzę, jest to, że węzeł .js jest dynamicznym językiem programowania (sprawdzanie typu), więc typy muszą być wyprowadzane w czasie wykonywania. Silnie typowane języki, takie jak C # .NET, teoretycznie mają znacznie większy potencjał, wygrywając w walce z Node .js (i PHP itp.), Szczególnie tam, gdzie jest to kosztowne obliczenie. Nawiasem mówiąc, .NET powinien mieć lepszą natywną współpracę z C / C ++ niż węzeł .js.