¿Node.js realmente aumenta la escalabilidad?

He estado leyendo sobre el problema C10K, y de particular interés es la parte que se refiere a la E / S asíncrona del servidor. http://www.kegel.com/c10k.html#aio

Creo que esto resume más o menos lo que Node.js hace en el servidor, al permitir que los subprocesos procesen las solicitudes de los usuarios mientras confía en las interrupciones de E / S (eventos) para notificar a los subprocesos los trabajos que se completan, en lugar de que el subproceso sea responsable del Trabajo de CPU completo. El hilo puede continuar con otras cosas (sin bloqueo) y recibir una notificación cuando se realiza un trabajo (por ejemplo, se encuentra un archivo o se comprime un video).

Posteriormente, esto significa que un subproceso está más 'disponible' para los sockets y, por lo tanto, para los usuarios del servidor.

Entonces encontré esto: http://teddziuba.com/2011/10/straight-talk-on-event-loops.html

¡El escritor aquí afirma que aunque el marco controlado por eventos (subprocesos interrumpidos) puede liberar subprocesos, en realidad no reduce la cantidad de trabajo que tiene que hacer una CPU! La razón aquí es que si, por ejemplo, un usuario solicita comprimir un video que cargó, la CPU todavía tiene que hacer este trabajo y se bloqueará mientras lo hace (por simplicidad, olvidemos el paralelismo aquí, a menos que usted ¡conocer mejor!).

Soy un codificador directo, no un administrador del servidor ni nada de eso. Solo me interesa saber: ¿Es Node.js un regalo de los dioses de la 'computación en la nube' o es todo aire caliente, y en realidad no ahorrará a las empresas tiempo y / o dinero al mejorar la escalabilidad?

Muchas gracias.

Por supuesto, cualquier trabajo vinculado a la CPU utilizará la CPU. Bloqueará la CPU en cualquier idioma o marco en el que la escriba.

Node.js es ideal para cuando tienes trabajo de E / S, no CPU. No haría levantamientos pesados ​​en Node, aunque se puede hacer. Node.js resuelve problemas reales , no ficticios o imaginarios, como los servidores de números de Fibonacci . No es "aire caliente".

Si bien el documento C10K está algo desactualizado con respecto a los detalles de implementación, la concurrencia basada en eventos (el modelo del reactor) sigue siendo en algunos aspectos superior a la programación preventiva. Por ejemplo, un modelo de programación preventiva puede programar subprocesos mientras están bloqueados por E / S. Esto permite que el nodo (y otras herramientas como Ruby's Event Machine y Python's Twisted) utilicen mejor los ciclos disponibles al pasar más tiempo haciendo trabajo real y menos tiempo bloqueando.

Multithreading todavía aumenta el rendimiento. La explicación original es idiota ya que no considera la existencia de múltiples núcleos. En el momento en que tiene más de un núcleo, los hilos no son más hilos. Son hyperthreads. Cualquier aplicación intensiva de subprocesos se beneficiará de ella más que una sola aplicación de subprocesos.