side - ¿Por qué es Node.js single threaded?
node.js server-side javascript (3)
El problema con el modelo de "un subproceso por solicitud" para un servidor es que no se escalan bien en varios escenarios en comparación con el modelo de subproceso de bucle de eventos.
Normalmente, en los escenarios de E / S intensivos, las solicitudes pasan la mayor parte del tiempo esperando que se complete la E / S. Durante este tiempo, en el modelo "un hilo por solicitud", los recursos vinculados al hilo (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 siguiente evento (E / S finalizada) para controlar. Así que 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 necesite abordar. Si tiene un escenario de E / S intensivo (como un proxy), se regirá el modelo base de eventos, mientras que un escenario intensivo de CPU con un número bajo de procesos concurrentes funcionará mejor con el modelo basado en subprocesos.
En el mundo real, la mayoría de los escenarios serán un poco intermedios. Necesitará 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 delega al backend para las tareas intensivas de CPU. El front-end utilizará pocos recursos para la tarea resultado.) Al igual que con cualquier sistema distribuido, requiere algún 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 el pie.
En servidores web basados en PHP (o Java / ASP.NET / Ruby), cada solicitud de cliente se crea una 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 se basan en eventos para que no bloqueen el bucle del subproceso principal.
Lo que no entiendo es ¿POR QUÉ el autor de Node lo eligió para ser de un solo hilo? Hace las cosas difíciles. Por ejemplo, no puedo ejecutar una función de uso intensivo de la CPU porque bloquea el subproceso principal (y se bloquean las nuevas solicitudes de los clientes), así que necesito generar un proceso (lo que significa que necesito crear un archivo JavaScript independiente y ejecutar otro proceso de nodo en él) ). Sin embargo, en PHP las tareas intensivas de 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 de subprocesos múltiples?
Nota: he usado la agrupación en clústeres para solucionar esto, pero no es bonito.
En pocas palabras, el nodo se basa en V8, que es internamente de un solo hilo. Hay formas de evitar las restricciones para las tareas intensivas de CPU.
En un punto (0.7), los autores intentaron introducir aislamientos como una forma de implementar múltiples subprocesos de cálculo, pero finalmente se eliminaron: https://groups.google.com/forum/#!msg/nodejs/zLzuo292hX0/F7gqfUiKi2sJ
Node.js fue creado explícitamente como un experimento en el procesamiento asíncrono. La teoría era que hacer el procesamiento asíncrono en un solo hilo podría proporcionar más rendimiento y escalabilidad en cargas web típicas que la implementación típica basada en hilos.
¿Y sabes qué? En mi opinión, esa teoría ha sido confirmada. Una aplicación node.js que no realiza tareas de uso intensivo de la CPU puede ejecutar miles de conexiones simultáneas más que Apache o IIS u otros servidores basados en subprocesos.
El solo hilo, la naturaleza asíncrona hace las cosas complicadas. ¿Pero honestamente crees que es más complicado que enhebrar? ¡Una condición de carrera puede arruinar todo el mes! ¡O vacíe su grupo de hilos debido a alguna configuración en algún lugar y observe cómo el tiempo de respuesta se reduce lentamente! Sin mencionar los puntos muertos, las inversiones de prioridad y todos los otros giros que van con el multihilo.
Al final, no creo que sea universalmente mejor o peor; Es diferente, ya veces es mejor y otras no. Utilice la herramienta adecuada para el trabajo.