Agarrando la alternativa de Node JS a multihilo

142

Si entiendo correctamente, el nodo JS no está bloqueando ... así que en lugar de esperar una respuesta de una base de datos u otro proceso, pasó a otra cosa y vuelve a comprobarlo más tarde.

También es de un solo hilo.

Entonces, todo esto significa que un proceso de Nodo JS determinado puede utilizar de manera completa y eficiente un solo núcleo de CPU, pero no utilizará ningún otro núcleo en la máquina, ya que nunca usará más de uno a la vez.

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

También en el caso de que el proceso Node JS tenga un bucle sin fin o una función de ejecución prolongada, ese proceso ya no es útil de ninguna manera hasta que se detenga el bucle sin fin o la función de ejecución prolongada (o se cancele todo el proceso).

¿Todo esto está bien? ¿Estoy correcto en mi entendimiento?

multithreading node.js

— Bryan Field
fuente

2

"Nodo" no tiene un solo subproceso. Solo el motor JS / V8 funciona en un solo hilo. La parte libuv de NodeJS es multiproceso. Ver ¿NodeJS es realmente de un solo hilo?

— RaelB

1

Enganchando stackoverflow.com/q/17959663/632951

— Pacerier

87

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

Así que me imagino que hará un uso limitado de otro núcleo para el grupo de subprocesos, por ejemplo, si realiza una lectura del sistema de archivos sin bloqueo, esto probablemente se implemente diciéndole a un subproceso del grupo de subprocesos que realice una lectura y establezca una devolución de llamada cuando está hecho, lo que significa que la lectura podría estar ocurriendo en un subproceso / núcleo diferente mientras el programa principal node.js está haciendo otra cosa.

Pero desde el punto de vista de node.js, es completamente único y no usará directamente más de un núcleo.

— jcoder
fuente

2

Todavía soy nuevo en Node.js y aprecio la discusión aquí. Solo quería señalar que hacer suposiciones de que las llamadas sin bloqueo están respaldadas por llamadas de bloqueo enhebradas probablemente no sea sabio (no es que @jcoder sugiera que el código del arquitecto se base en estas suposiciones). En este caso, incluso si IO se maneja en un hilo separado con una llamada de bloqueo, ese hilo básicamente esperará al IO de todos modos, por lo que no utilizará otros núcleos / CPU. Codifique la fuerza de las herramientas que está utilizando y no se preocupe demasiado por los detalles de bajo nivel (hasta que se conviertan en un problema).

— wbyoung

para que podamos hacer otras ventajas usando la devolución de llamada como código javascript en la interfaz de

— usuario

37

Sí, diría que tu comprensión es completamente correcta. Este artículo ( archivado ) explica bastante bien la lógica detrás de este diseño. Este es probablemente el párrafo más importante:

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

— Michael Borgwardt
fuente

El articulo es falso. Aunque existe un apache multiproceso mpm, es incompatible con prácticamente todas las configuraciones de uso diario. Apache es multiproceso, y no multiproceso hasta ahora, y lo será, probablemente para siempre. Me parece catastrófico, manipular los significados adecuados de la terminología es solo un buen intento de ocultar el problema, en lugar de resolverlo.

— peterh - Restablece a Mónica el

1

@peterh No tienes sentido. El artículo es completamente correcto, indicando que apache es multiproceso o multiproceso dependiendo de la configuración. El caso de multiprocesos es aún peor con respecto al manejo de muchas conexiones, que es la única razón por la que se menciona Apache en primer lugar. Además, el módulo PHP muy comúnmente utilizado es multiproceso por sí mismo. Y finalmente, aunque no soy un experto en apache, mi impresión de otros artículos es que el MPM trabajador es, de hecho, muy utilizado.

— Michael Borgwardt

@MichaelBorgwardt Sí, apache puede ser multiproceso y también multiproceso, no lo negué. Pero php es incompatible con la configuración multiproceso, y si usted fuera un experto en apache seguramente lo sabría. El módulo php muy utilizado no es multiproceso. Tu información es falsa. Sugiero probar una configuración de prueba y verá. Es un hecho real, no es cuestión de debate, pruébalo y verás.

— peterh - Restablece a Mónica el

27

Incluso si este es un hilo viejo, pensé, que compartiría con una idea, cómo utilizar más de un núcleo en la aplicación Node.JS. 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 (puede cambiarlo con jxcore.tasks.setThreadCount())

Por supuesto, hay mucho más que puedes hacer con las tareas. Los documentos están aquí .

Pocos artículos sobre ese tema:

— infografnet
fuente

13

Desde esta pregunta hace casi 2 años. Las cosas se están volviendo diferentes o hay enfoques alternativos para el problema de subprocesos múltiples en Node.JS

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

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

— Nuray Altin
fuente

1

Node.js es una aplicación de subproceso único, pero puede admitir concurrencia a través del concepto de evento y devoluciones de llamada. Aquí hay un video de Philip Roberts que explica cómo funcionan los bucles de eventos en JavaScript.

Haga clic aquí para ver el video

(En lugar de WebAPI, hay API de C ++ en Node.js)

— Saurabh Lende
fuente

2

Esto debería ser un comentario

— Cherniv