Desempenho do Node.js vs .Net

Eu li muito sobre o Node.js ser rápido e capaz de acomodar grandes quantidades de carga. Alguém tem alguma evidência do mundo real disso versus outros frameworks, particularmente o .Net? A maioria dos artigos que li são anedóticos ou não têm comparações com o .Net.

obrigado

Ser RÁPIDO e lidar com muita carga são duas coisas diferentes. Um servidor que é realmente RÁPIDO ao atender uma solicitação por segundo pode coaxar totalmente se você enviar 500 solicitações por segundo (em LOAD ).

Você também deve considerar páginas estáticas (e armazenadas em cache) versus páginas dinâmicas. Se você estiver preocupado com páginas estáticas, o IIS provavelmente vencerá o nó porque o IIS usa o cache no modo kernel, o que significa que as solicitações que solicitam uma página estática nem saem do kernel.

Suponho que você esteja procurando uma comparação entre o ASP.NET e o nó. Nesta batalha, depois que tudo tiver sido compilado / interpretado, você provavelmente terá um desempenho muito próximo. Talvez o .NET seja um pouco MAIS RÁPIDO ou talvez o nó seja um pouco MAIS RÁPIDO , mas provavelmente está perto o suficiente para você não se importar. Eu apostaria no .NET, mas não tenho certeza.

O local em que o nó é realmente atraente é para lidar com LOAD . É aqui que as tecnologias realmente diferem. O ASP.NET dedica um encadeamento para cada solicitação do seu pool de encadeamentos e, uma vez esgotado o ASP.NET, todas as solicitações de encadeamentos disponíveis começam a ficar na fila. Se você estiver exibindo aplicativos "Hello World", como o exemplo de @shankar, isso pode não importar muito, porque os threads não serão bloqueados e você poderá lidar com muitas solicitações antes de você ficar sem threads. O problema com o modelo ASP.NET ocorre quando você começa a fazer solicitações de E / S que bloqueiam o encadeamento (chame um banco de dados, faça uma solicitação http para um serviço, leia um arquivo do disco). Essas solicitações de bloqueio significam que seu thread valioso do pool de threads não está fazendo nada. Quanto mais bloqueio você tiver,CARREGAR seu aplicativo ASP.NET poderá veicular.

Para evitar esse bloqueio, use as portas de conclusão de E / S que não exigem retenção de um encadeamento enquanto você espera por uma resposta. O ASP.NET suporta isso, mas infelizmente muitas das estruturas / bibliotecas comuns no .NET NÃO. Por exemplo, o ADO.NET suporta portas de conclusão de E / S, mas o Entity Framework não as utiliza. Portanto, você pode criar um aplicativo ASP.NET que seja puramente assíncrono e lide com muita carga, mas a maioria das pessoas não, porque não é tão fácil quanto criar um que seja síncrono e talvez você não consiga usar algumas de suas partes favoritas da estrutura (como linq para entidades) se você o fizer.

O problema é que o ASP.NET (e o .NET Framework) foi criado para não opinar sobre E / S assíncrona. O .NET não se importa se você escreve código síncrono ou assíncrono; portanto, cabe ao desenvolvedor tomar essa decisão. Parte disso ocorre porque o threading e a programação com operações assíncronas eram considerados "difíceis", e o .NET queria fazer todo mundo feliz (noobs e especialistas). Ficou ainda mais difícil porque o .NET acabou com 3-4 padrões diferentes para executar assíncrona. O .NET 4.5 está tentando voltar e adaptar a estrutura .NET para ter um modelo opinativo em torno da E / S assíncrona, mas pode demorar um pouco até que as estruturas de que você se preocupe realmente a suportem.

Os projetistas do nó, por outro lado, fizeram uma escolha opinativa de que TODAS as E / S deveriam ser assíncronas. Por causa dessa decisão, os designers do nó também foram capazes de decidir que cada instância do nó seria encadeada única para minimizar a troca de encadeamentos e que um encadeamento executaria apenas o código que estava na fila. Pode ser uma nova solicitação, pode ser o retorno de chamada de um pedido de banco de dados, pode ser o retorno de chamada de uma solicitação de descanso http que você fez. O nó tenta maximizar a eficiência da CPU, eliminando as opções de contexto do encadeamento. Como o nó fez essa escolha opinativa de que TODAS as E / S são assíncronas, isso também significa que todas as suas estruturas / complementos suportam essa opção. É mais fácil escrever aplicativos 100% assíncronos no nó (porque o nó obriga a gravar aplicativos assíncronos).

Novamente, não tenho números concretos para provar de uma maneira ou de outra, mas acho que o nó venceria a competição LOAD pelo aplicativo da Web típico. Um aplicativo .NET altamente otimizado (100% assíncrono) pode dar ao aplicativo node.js equivalente uma corrida por seu dinheiro, mas se você fizer uma média de todos os aplicativos .NET e de todos os aplicativos existentes, provavelmente o nó provavelmente lidará com mais CARGA.

Espero que ajude.

Fiz um teste de desempenho rudimentar entre o nodejs e o IIS. O IIS é cerca de 2,5 vezes mais rápido que o nodejs ao exibir "olá, mundo!". código abaixo.

meu hardware: Dell Latitude E6510, Core i5 (núcleo duplo), 8 GB de RAM, sistema operacional Windows 7 Enterprise de 64 bits

servidor de nó

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>

meu próprio programa de benchmark usando a biblioteca paralela de tarefas:

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

}
}

e resultados:

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

conclusão: o IIS é mais rápido que o nodejs em cerca de 2,5 vezes (no Windows). Este é um teste muito rudimentar e de forma alguma conclusivo. Mas acredito que este é um bom ponto de partida. O Nodejs provavelmente é mais rápido em outros servidores Web, em outras plataformas, mas no Windows o IIS é o vencedor. Os desenvolvedores que desejam converter seu ASP.NET MVC em nodejs devem fazer uma pausa e pensar duas vezes antes de continuar.

Atualizado (17/5/2012) O Tomcat (no Windows) parece derrotar o IIS, cerca de três vezes mais rápido que o IIS na distribuição de html estático.

tomcat

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

resultados 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

conclusão atualizada: executei o programa de benchmark várias vezes. O Tomcat parece ser o servidor mais rápido na distribuição de HTML ESTÁTICO, NO WINDOWS.

Atualizado (18/5/2012) Anteriormente, eu tinha 100.000 solicitações no total com 10.000 solicitações simultâneas. Aumentei para 1.000.000 de solicitações totais e 100.000 solicitações simultâneas. O IIS aparece como o vencedor, com os Nodejs sendo os piores. Eu tabulei os resultados abaixo:

.

Os servidores NIO (Node.js etc.) tendem a ser mais rápidos que os servidores BIO. (IIS etc). Para apoiar minha reivindicação, a TechEmpower é uma empresa especializada em benchmarks de estrutura da web . Eles são muito abertos e têm uma maneira padrão de testar todas as estruturas de quadro.

Atualmente, os testes da Rodada 9 são os mais recentes (maio de 2014). Existem muitos tipos de IIS testados, mas o aspnet stripped parece ser a variante mais rápida do IIS.

Aqui estão os resultados em respostas por segundo ( quanto maior, melhor):

• Serialização JSON
  • nodejs: 228,887
  • sem aspnet: 105,272
• Consulta única
  • nodejs-mysql: 88,597
  • aspnet-stripped-raw: 47,066
• Várias consultas
  • nodejs-mysql: 8,878
  • aspnet-stripped-raw: 3,915
• Texto simples
  • nodejs: 289,578
  • sem aspnet: 109,136

Em todos os casos, o Node.js tende a ser 2x mais rápido que o IIS.

Eu tenho que concordar com Marcus Granstrom, o cenário é muito importante aqui.

Para ser sincero, parece que você está tomando uma decisão arquitetônica de alto impacto. Meu conselho seria isolar as áreas de preocupação e fazer uma "pausa" entre as pilhas que você está considerando.

No final do dia, você é responsável pela decisão e não acho que a desculpa "Um cara do Stackoverflow me mostrou um artigo que dizia que seria bom" Vai resolver isso com seu chefe.

A principal diferença que vejo é que o nó .js é uma linguagem de programação dinâmica (verificação de tipo), portanto, os tipos devem ser derivados em tempo de execução. As linguagens fortemente tipadas, como o C # .NET, teoricamente, têm muito mais chances de vencer a luta contra o Nó .js (e PHP etc.), especialmente onde é caro o cálculo. A propósito, o .NET deve ter melhor interoperação nativa com C / C ++ do que o nó .js.