Estou fazendo um teste rápido de estresse em dois (meio) hello world projects escritos em node.js e asp.net-core. Ambos estão sendo executados no modo de produção e sem um criador de logs anexado a eles. O resultado é surpreendente! O núcleo do ASP.NET está superando o aplicativo node.js. mesmo após um trabalho extra, enquanto o aplicativo node.js. está apenas renderizando uma exibição.

App 1: http://localhost:3000/nodejs node.js

Usando : node.js, mecanismo de renderização express e vash.

O código neste terminal é

router.get('/', function(req, res, next) {
  var vm = {
    title: 'Express',
    time: new Date()
  }
  res.render('index', vm);
});

Como você pode ver, ele não faz nada além de enviar a data atual através da timevariável para a visualização.

App 2: http://localhost:5000/aspnet-core asp.net core

Usando : ASP.NET Core, segmentação de modelo padrãodnxcore50

No entanto, este aplicativo faz algo diferente de apenas renderizar uma página com uma data nela. Ele gera 5 parágrafos de vários textos aleatórios. Teoricamente, isso deve tornar isso um pouco mais pesado que o aplicativo nodejs.

Aqui está o método de ação que renderiza esta página

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

Resultado do teste de estresse

Resultado do teste de estresse do aplicativo Node.js

Atualização: Seguindo sugestão de Gorgi Kosev

Usando npm install -g recluster-cli && NODE_ENV=production recluster-cli app.js 8

Resultado do teste de estresse do aplicativo ASP.NET Core

Não posso acreditar nos meus olhos! Não é verdade que, neste teste básico, o núcleo do asp.net é muito mais rápido que o nodejs. É claro que essa não é a única métrica usada para medir o desempenho entre essas duas tecnologias da web, mas estou me perguntando o que estou fazendo de errado no lado do node.js. .

Sendo um desenvolvedor profissional do asp.net e desejando adaptar o node.js em projetos pessoais, isso me deixa de lado - já que estou um pouco paranóico com relação ao desempenho. Eu pensei que o node.js é mais rápido que o núcleo do asp.net (em geral - como visto em vários outros benchmarks) - só quero provar isso para mim mesmo (para me encorajar a adaptar o node.js.).

Por favor, responda no comentário se você quiser que eu inclua mais trechos de código.

Atualização: distribuição de tempo do aplicativo .NET Core

Resposta do servidor

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

Como muitos outros aludiram, a comparação carece de contexto.
No momento do seu lançamento, a abordagem assíncrona do node.js era revolucionária. Desde então, outras linguagens e estruturas da web adotam as abordagens adotadas na corrente principal.

Para entender o significado da diferença, você precisa simular uma solicitação de bloqueio que represente alguma carga de trabalho de E / S, como uma solicitação de banco de dados. Em um sistema de encadeamento por solicitação, isso esgotará o conjunto de encadeamentos e novas solicitações serão colocadas em uma fila aguardando um encadeamento disponível.
Com estruturas sem bloqueio de io, isso não acontece.

Considere este servidor node.js que espera 1 segundo antes de responder

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

Agora vamos lançar 100 conencções simultâneas, por 10s. Portanto, esperamos que cerca de 1.000 solicitações sejam concluídas.

$ 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

Como você pode ver, entramos no estádio com 922 concluídos.

Agora, considere o seguinte código asp.net, escrito como se async / waitit ainda não fosse suportado, portanto, remonta à época de lançamento do 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! Aqui vemos o limite do pool de threads. Ao ajustá-lo, podemos obter mais solicitações simultâneas, mas à custa de mais recursos do servidor.

Para essas cargas de trabalho ligadas à E / S, a ação para evitar o bloqueio dos encadeamentos de processamento foi tão dramática.

Agora, vamos trazê-lo para hoje, onde essa influência se espalhou pelo setor e permitir que a dotnet aproveite suas melhorias.

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

Sem surpresas aqui, agora combinamos o node.js.

Então, o que tudo isso significa?

Suas impressões de que o node.js é o "mais rápido" vêm de uma época em que não vivemos mais. Acrescente a isso que nunca foi o nó / js / v8 que foi "rápido", mas que eles quebraram o encadeamento por solicitação modelo. Todo mundo está se atualizando.

Se o seu objetivo é o processamento mais rápido possível de solicitações únicas, observe os benchmarks sérios em vez de criar os seus próprios. Mas se o que você deseja é simplesmente algo que se adapta aos padrões modernos, escolha o idioma que você gosta e verifique se não está bloqueando esses tópicos.

Isenção de responsabilidade: Todo o código escrito e os testes são executados em um MacBook Air antigo durante uma sonolenta manhã de domingo. Sinta-se à vontade para pegar o código e testá-lo no Windows ou ajustar suas necessidades - https://github.com/csainty/nodejs-vs-aspnetcore

Estruturas de nós como Express e Koa têm uma sobrecarga terrível. O nó "Raw" é significativamente mais rápido.

Eu não tentei, mas há uma estrutura mais nova que se aproxima muito do desempenho do nó "Raw": https://github.com/aerojs/aero

(veja benchmark nessa página)

update: Aqui estão algumas figuras: 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

Como você pode ver, as despesas gerais nas estruturas node.js mais populares são MUITO significativas!