Cette question peut sembler élémentaire, mais je n'ai pas trouvé de documentation :
Quelle est la différence entre forker et spawner un processus node.js ? J'ai lu que le forking est un cas particulier du spawning, mais quels sont les différents cas d'utilisation et les raisons d'utiliser chacun d'entre eux ?
Spawn est une commande conçue pour exécuter des commandes système. Lorsque vous exécutez spawn, vous lui envoyez une commande système qui sera exécutée sur son propre processus, mais n'exécute pas d'autre code dans votre processus de nœud. Vous pouvez ajouter des écouteurs pour le processus que vous avez spawné, afin de permettre à votre code d'interagir avec le processus spawné, mais aucune nouvelle instance de V8 n'est créée (à moins bien sûr que votre commande soit une autre commande Node, mais dans ce cas vous devriez utiliser fork !) et une seule copie de votre module node est active sur le processeur.
Fork est une instance spéciale de spawn, qui exécute une nouvelle instance du moteur V8. En d'autres termes, vous pouvez essentiellement créer plusieurs travailleurs, fonctionnant sur la même base de code Node, ou peut-être un module différent pour une tâche spécifique. Ceci est très utile pour créer un pool de travailleurs. Alors que le modèle d'événement asynchrone de Node permet d'utiliser assez efficacement un seul cœur de machine, il ne permet pas à un processus de nœud d'utiliser des machines à plusieurs cœurs. Le moyen le plus simple d'y parvenir est d'exécuter plusieurs copies du même programme, sur un seul processeur.
Une bonne règle empirique est un à deux processus de nœud par cœur, peut-être plus pour les machines avec un bon ratio horloge RAM/horloge CPU, ou pour les processus de nœud lourds en E/S et légers en travail CPU, pour minimiser le temps d'arrêt de la boucle d'événement en attente de nouveaux événements. Cependant, cette dernière suggestion est une micro-optimisation, et nécessiterait un benchmarking minutieux pour s'assurer que votre situation correspond au besoin de nombreux processus/cœur. Vous pouvez en fait diminuer les performances en créant trop de travailleurs pour votre machine/scénario.
En fin de compte, vous pourriez utiliser spawn d'une manière qui fait ce qui précède, en envoyant à spawn une commande Node. Mais ce serait stupide, car fork fait certaines choses pour optimiser le processus de création des instances V8. Je tiens à préciser qu'en fin de compte, spawn englobe fork. Fork est juste optimal pour ce cas d'utilisation particulier et très utile.
http://nodejs.org/api/child_process.html#child_process_child_process_exec_command_options_callback
@ChrisCM, si j'utilise disons var child = require('child_process').fork('child.js'); Par exemple, dans mon application principale, j'ai maintenant deux cœurs distincts qui fonctionnent. Si je lance un lourd for dans child.js (processus), j'utiliserais essentiellement plus de cœurs pour alimenter child.js, n'est-ce pas ? Cette utilisation du processeur affecterait-elle le cœur de mon application principale ?
Il est impossible de faire quoi que ce soit sur un CPU sans affecter d'autres choses. Ordonnancement, utilisation du cache partagé, trafic du BUS, etc. Cependant, il devrait tirer parti d'un noyau séparé et laisser votre boucle d'exécution principale le plus souvent non affectée. C'est-à-dire qu'il n'y aura pas les effets négatifs graves que l'on pourrait attendre de l'exécution de deux processus sur le même processeur à un seul cœur. À ce stade, c'est vraiment au système d'exploitation et à la configuration matérielle de l'optimiser correctement. Des configurations différentes peuvent donner des résultats différents.
@ChrisCM Oui, j'utilise un MonsterLoop global pour synchroniser le positionnement des monstres et cet objet qu'il itère peut avoir jusqu'à 5 000 clés. Je l'itère toutes les 2 secondes et la bifurcation semble détruire des centaines d'utilisations de mémoire de mon CPU (celui du jeu principal). Je préférerais procéder de cette façon plutôt que de regrouper cette boucle et de la faire tourner xx fois par cœur que j'ai... Ty pour votre perspicacité ~ Maintenant, je ne sais pas si je dois utiliser Redis ou l'IPC interne :P
Lorsque spawn est appelé, il crée un interface de diffusion en continu entre le processus parent et le processus enfant. Interface de diffusion en continu - mise en mémoire tampon ponctuelle de données dans un format binaire.
Lorsque fork est appelé, il crée un canal de communication entre le processus parent et enfant Canal de communication - messagerie
Si les deux se ressemblent beaucoup dans la façon dont ils transfèrent les données, il y a quelques différences.
JSON o XML messages de données.Spawn doit être utilisé pour transmettre de grandes quantités de données, comme des images, du processus spawn au processus parent.
La fourche doit être utilisée pour envoyer JSON o XML messages. Par exemple, supposons que dix processus bifurqués sont créés à partir du processus parent. Chaque processus effectue une opération. Pour chaque processus, l'achèvement de l'opération enverra un message au processus parent indiquant quelque chose comme "Process #4 done" o "Process #8 done" .
La méthode child_process.spawn lance un nouveau processus avec une commande donnée. Elle a la signature suivante
child_process.spawn(command[, args][, options])Plus d'informations sur options
La méthode spawn() renvoie des flux (stdout &stderr) et elle doit être utilisée lorsque le processus renvoie une quantité importante de données. spawn() commence à recevoir la réponse dès que le processus commence à s'exécuter.
processus_enfant.bifurcation est un cas particulier de la méthode spawn() pour créer des processus Node. Il a la signature suivante
child_process.fork(modulePath[, args][, options])La méthode fork renvoie un objet avec un canal de communication intégré en plus d'avoir toutes les méthodes d'une instance ChildProcess normale.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
