Agarrando la alternativa Nodo JS para multithreading

Question

Si he entendido bien Nodo JS es no bloqueante ... así que en vez de esperar a una respuesta de una base de datos u otro proceso se trasladó a otra cosa y comprueba de nuevo más tarde.

También es de rosca simple.

Todo esto significa que un proceso Node JS determinado puede utilizar total y eficientemente un solo núcleo de CPU, pero no usará ningún otro núcleo en la máquina, como en, nunca usará más de uno a la vez.

Esto, por supuesto, significa que las otras CPU pueden ser utilizadas por otros procesos para cosas como la base de datos SQL u otras subrutinas pesadas de la CPU intencionalmente separadas, siempre que sean un proceso separado.

También en el caso de que el proceso Node JS tenga un bucle infinito o una función de larga ejecución, ese proceso ya no es útil hasta que se detiene el bucle infinito o la función de larga ejecución (o se cancela todo el proceso).

¿Todo esto está bien? ¿Estoy en lo correcto en mi comprensión?

Answer 1

Más o menos correcta, sí. El servidor node.js tiene un grupo de subprocesos interno para que pueda realizar operaciones de bloqueo y notificar al hilo principal con una devolución de llamada o evento cuando las cosas se completen.

Así que imagino que hará un uso limitado de otro núcleo para el grupo de subprocesos, por ejemplo, si hace un sistema de archivos sin bloqueo, es probable que esto se implemente contando un subproceso del grupo de subprocesos para realizar una lectura y establecer una devolución de llamada cuando está hecho, lo que significa que la lectura podría estar sucediendo en un subproceso/núcleo diferente, mientras que el programa principal node.js está haciendo otra cosa.

Pero desde un punto de vista node.js, es enteramente de un solo subproceso y no usar directamente más de un núcleo.

Answer 2

Sí, yo diría que su comprensión es completamente correcta. This article (archived) explica bastante bien el razonamiento detrás de este diseño. Este es probablemente el párrafo más importante:

Apache es multiproceso: genera un hilo por solicitud (o proceso, depende de la conf). Puede ver cómo esa sobrecarga consume memoria a medida que aumenta el número de conexiones simultáneas y se necesitan más hilos para servir a múltiples clientes simultáneos. Nginx y Node.js no son multiproceso, porque los hilos y procesos conllevan un gran costo de memoria. Son de subproceso único, pero basados ​​en eventos. Esto elimina la sobrecarga creada por miles de subprocesos/procesos al manejar muchas conexiones en un solo subproceso.

Answer 3

Ya que esta pregunta fue hecha hace casi 2 años. Las cosas se están haciendo diferentes o hay enfoques alternativos al problema de subprocesamiento múltiple en Node.JS

De acuerdo con la siguiente publicación de blog, usando la extensión de 'tarea' entrante, algunos pueden beneficiarse directamente de otros núcleos disponibles.

http://oguzbastemur.blogspot.com/2013/12/multithread-nodejs.html

Answer 4

Incluso si se trata de un viejo hilo, pensé, que iba a compartir con una idea, la forma de utilizar más de un núcleo en Node.JS aplicación. Como Nuray Altin ha mencionado, JXcore puede hacer eso.

ejemplo simple:

var method = function() { 
    console.log("this is message from thread no", process.threadId); 
}; 

jxcore.tasks.runOnThread(0, method); 
jxcore.tasks.runOnThread(1, method); 

// this is message from thread no 1 
// this is message from thread no 0 

Por defecto hay dos hilos (se puede cambiar con jxcore.tasks.setThreadCount())

Por supuesto hay mucho más que se puede hacer con las tareas. Los documentos son here.

algunos artículos sobre el tema:

• How multithreaded JXcore applications benefit from multiple cores.
• How to turn your existing application into a multithreaded one with a few lines of code!

Answer 5

Node.js es una aplicación de un solo subproceso, pero que puede soportar la concurrencia a través del concepto de evento y devoluciones de llamada. Aquí está el video por Philip Roberts que explica cómo funcionan los bucles de eventos en JavaScript.

Click here to see the video

(En lugar de WebAPIs hay APIs de C++ en Node.js)