En servidores web basados en PHP (o Java / ASP.NET / Ruby), cada solicitud de cliente se instancia en un nuevo hilo. Pero en Node.js todos los clientes se ejecutan en el mismo subproceso (¡incluso pueden compartir las mismas variables!) Entiendo que las operaciones de E / S están basadas en eventos, por lo que no bloquean el bucle del subproceso principal.
Lo que no entiendo es ¿POR QUÉ el autor de Node lo eligió para un solo subproceso? Hace las cosas difíciles. Por ejemplo, no puedo ejecutar una función intensiva de CPU porque bloquea el subproceso principal (y las nuevas solicitudes de los clientes están bloqueadas), así que necesito generar un proceso (lo que significa que necesito crear un archivo JavaScript separado y ejecutar otro proceso de nodo en eso). Sin embargo, en PHP, las tareas intensivas de la CPU no bloquean a otros clientes porque, como mencioné, cada cliente está en un hilo diferente. ¿Cuáles son sus ventajas en comparación con los servidores web multiproceso?
Nota: He usado el agrupamiento para evitar esto, pero no es bonito.
node -e 'setTimeout(()=>{},1000);' & ps -T h $! | wc -l; kill $!muestra cinco hilos en mi sistema. El bucle de eventos principal es de un solo subproceso (no tendría mucho sentido si no lo fuera), pero Node tiene muchos subprocesos múltiples y puede escribir aplicaciones de un solo proceso de subprocesos múltiples si lo desea. Me encantaría escribir una respuesta integral al respecto, pero algunas personas decidieron cerrar su pregunta, por lo que no puedo. Estoy votando para reabrirlo. Si obtiene más votos y se vuelve a abrir, por favor, mencióneme en el comentario.Respuestas:
Node.js se creó explícitamente como un experimento en el procesamiento asíncrono. La teoría era que el procesamiento asíncrono en un solo subproceso podría proporcionar más rendimiento y escalabilidad bajo cargas web típicas que la implementación típica basada en subprocesos.
¿Y sabes qué? En mi opinión, esa teoría ha sido confirmada. Una aplicación node.js que no hace cosas intensivas en CPU puede ejecutar miles de conexiones simultáneas más que Apache o IIS u otros servidores basados en hilos.
La naturaleza asincrónica de un solo subproceso complica las cosas. ¿Pero honestamente crees que es más complicado que enhebrar? ¡Una condición de carrera puede arruinar todo tu mes! ¡O vacíe su grupo de subprocesos debido a alguna configuración en alguna parte y observe cómo su tiempo de respuesta se ralentiza! Sin mencionar los puntos muertos, las inversiones prioritarias y todos los otros giros que van con el subprocesamiento múltiple.
Al final, no creo que sea universalmente mejor o peor; es diferente, y algunas veces es mejor y otras no. Use la herramienta adecuada para el trabajo.
fuente
El problema con el modelo de "un subproceso por solicitud" para un servidor es que no se escalan bien para varios escenarios en comparación con el modelo de subproceso de bucle de eventos.
Por lo general, en escenarios intensivos de E / S, las solicitudes pasan la mayor parte del tiempo esperando que se complete la E / S. Durante este tiempo, en el modelo de "un subproceso por solicitud", los recursos vinculados al subproceso (como la memoria) no se utilizan y la memoria es el factor limitante. En el modelo de bucle de eventos, el hilo del bucle selecciona el próximo evento (E / S terminado) para manejar. Por lo tanto, el hilo siempre está ocupado (si lo programa correctamente, por supuesto).
El modelo de bucle de eventos como todas las cosas nuevas parece brillante y la solución para todos los problemas, pero qué modelo usar dependerá del escenario que deba abordar. Si tiene un escenario de E / S intensivo (como un proxy), el modelo base de eventos gobernará, mientras que un escenario intensivo de CPU con un bajo número de procesos concurrentes funcionará mejor con el modelo basado en subprocesos.
En el mundo real, la mayoría de los escenarios estarán un poco en el medio. Deberá equilibrar la necesidad real de escalabilidad con la complejidad del desarrollo para encontrar la arquitectura correcta (por ejemplo, tener un front-end de base de eventos que delegue en el back-end para las tareas intensivas de la CPU. El front-end usará pocos recursos esperando la tarea resultado.) Al igual que con cualquier sistema distribuido, requiere un poco de esfuerzo para que funcione.
Si está buscando la bala de plata que se ajuste a cualquier escenario sin ningún esfuerzo, terminará con una bala en su pie.
fuente
En pocas palabras, el nodo se basa en V8, que tiene un solo subproceso interno. Hay formas de evitar las restricciones para las tareas intensivas de CPU.
En un momento (0.7), los autores intentaron introducir aislamientos como una forma de implementar múltiples hilos de cálculo, pero finalmente fueron eliminados: https://groups.google.com/forum/#!msg/nodejs/zLzuo292hX0/F7gqfUiKi2sJ
fuente