O Node.js realmente aumenta a escalabilidade?

Eu tenho lido sobre o problema C10K e, principalmente, é a parte que se refere à E / S do servidor assíncrono. http://www.kegel.com/c10k.html#aio

Acredito que isso resume muito bem o que o Node.js faz no servidor, permitindo que os threads processem solicitações do usuário enquanto dependem de interrupções de E / S (eventos) para notificar os threads dos trabalhos concluídos, em vez de serem responsáveis ​​pelo trabalho completo da CPU. O thread pode continuar com outras coisas (sem bloqueio) e ser notificado sobre quando um trabalho é concluído (por exemplo, um arquivo é encontrado ou um vídeo é compactado).

Posteriormente, isso significa que um encadeamento está mais 'disponível' para soquetes e, portanto, para usuários no servidor.

Então eu encontrei o seguinte: http://teddziuba.com/2011/10/straight-talk-on-event-loops.html

O escritor aqui afirma que, embora a estrutura orientada a eventos (encadeamento interrompido) possa liberar threads, na verdade não reduz a quantidade de trabalho que uma CPU precisa fazer! A lógica aqui é que, se, digamos, um usuário solicitar a compactação de um vídeo enviado, a CPU ainda precisará executar esse trabalho e estará bloqueando enquanto o faz (por uma questão de simplicidade, vamos esquecer o paralelismo aqui - a menos que você conhecer melhor!).

Eu sou um codificador direto, não um administrador de servidor ou algo assim. Só estou interessado em saber: o Node.js é um presente dos deuses da 'computação em nuvem' ou é tudo um ar quente, e na verdade não economiza tempo e / ou dinheiro das empresas, melhorando a escalabilidade?

Muito Obrigado.

Obviamente, qualquer trabalho vinculado à CPU utilizará a CPU. Isso bloqueará a CPU em qualquer idioma ou estrutura em que você a escrever.

O Node.js é ótimo para quando você tem um trabalho vinculado à E / S, não à CPU. Eu não faria trabalho pesado no Node, embora isso possa ser feito. O Node.js resolve problemas reais , não imaginários ou imaginários, como os servidores de números fibonacci . Não é "ar quente".

Embora o documento C10K esteja um pouco desatualizado em relação aos detalhes da implementação, a simultaneidade baseada em eventos (o modelo do reator) ainda é, de certa forma, superior ao agendamento preventivo. Por exemplo, um modelo de agendamento preventivo pode agendar encadeamentos enquanto estão bloqueados por IO. Isso permite que o nó (e outras ferramentas como Ruby's Event Machine e Twisted do Python) usem melhor os ciclos disponíveis, gastando mais tempo realizando um trabalho real e menos tempo bloqueando.

O multithreading ainda aumenta o desempenho. A explicação original é idiota, pois não considera a existência de múltiplos núcleos. No momento em que você tem mais de um núcleo, os threads não são mais threads. Eles são hyperthreads. Qualquer aplicativo intensivo de encadeamento se beneficiará mais do que um único aplicativo encadeado.