Comprendre l'alternative Node JS au multithreading

Si je comprends bien, Node JS n'est pas bloquant ... donc au lieu d'attendre une réponse d'une base de données ou d'un autre processus, il est passé à autre chose et revérifie plus tard.

Il est également à filetage unique.

Tout cela signifie-t-il qu'un processus Node JS donné peut utiliser pleinement et efficacement un seul cœur de processeur, mais il n'utilisera aucun autre cœur sur la machine, car dans, il n'en utilisera jamais plus d'un à la fois.

Cela signifie bien sûr que les autres processeurs peuvent toujours être utilisés par d'autres processus pour des choses comme la base de données SQL ou d'autres sous-routines lourdes de processeur intentionnellement séparées tant qu'il s'agit d'un processus séparé.

De plus, dans le cas où le processus Node JS a une boucle sans fin ou une fonction à exécution longue, ce processus n'est plus utile en aucune façon jusqu'à ce que la boucle sans fin ou la fonction à exécution longue soit arrêtée (ou tout le processus tué).

Est-ce que tout cela est bien? Ai-je raison dans ma compréhension?

Assez correct, oui. Le serveur node.js a un pool de threads interne afin qu'il puisse effectuer des opérations de blocage et notifier le thread principal avec un rappel ou un événement lorsque les choses sont terminées.

J'imagine donc qu'il utilisera de manière limitée un autre noyau pour le pool de threads, par exemple si vous lisez un système de fichiers non bloquant, cela est probablement implémenté en disant à un thread du pool de threads d'effectuer une lecture et de définir un rappel lorsque c'est fait, ce qui signifie que la lecture peut avoir lieu sur un thread / core différent pendant que le programme principal node.js fait autre chose.

Mais du point de vue node.js, il est entièrement mono-thread et n'utilisera pas directement plus d'un cœur.

Oui, je dirais que votre compréhension est tout à fait correcte. Cet article ( archivé ) explique assez bien la raison d'être de cette conception. C'est probablement le paragraphe le plus important:

Apache est multithread: il génère un thread par requête (ou processus, cela dépend de la conf). Vous pouvez voir comment cette surcharge consomme de la mémoire à mesure que le nombre de connexions simultanées augmente et que davantage de threads sont nécessaires pour servir plusieurs clients simultanés. Nginx et Node.js ne sont pas multithread, car les threads et les processus coûtent beaucoup de mémoire. Ils sont à thread unique, mais basés sur des événements. Cela élimine la surcharge créée par des milliers de threads / processus en gérant de nombreuses connexions dans un seul thread.

Même s'il s'agit d'un vieux fil, j'ai pensé que je partagerais avec une idée, comment utiliser plus d'un noyau dans l'application Node.JS. Comme Nuray Altin l'a mentionné - JXcore peut le faire.

Exemple 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

Par défaut, il y a deux threads (vous pouvez le changer avec jxcore.tasks.setThreadCount())

Bien sûr, vous pouvez faire beaucoup plus avec les tâches. Les documents sont ici .

Quelques articles sur ce sujet:

• Comment les applications JXcore multithread bénéficient de plusieurs cœurs .
• Comment transformer votre application existante en une application multithread avec quelques lignes de code!

Depuis cette question posée il y a presque 2 ans. Les choses deviennent différentes ou il existe des approches alternatives au problème de multithreading sur Node.JS

Selon l'article de blog ci-dessous, en utilisant l'extension `` tâche '' entrante, certains peuvent bénéficier directement d'autres cœurs disponibles.

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

Node.js est une application à un seul thread, mais elle peut prendre en charge la concurrence via le concept d'événement et de rappels. Voici une vidéo de Philip Roberts qui explique comment les boucles d'événements fonctionnent en javascript.

Cliquez ici pour voir la vidéo

(Au lieu des WebAPI, il existe des API C ++ dans Node.js)