Pourquoi Node.js est-il unitaire? [fermé]

Dans les serveurs Web basés sur PHP (ou Java / ASP.NET / Ruby), chaque demande client est instanciée sur un nouveau thread. Mais dans Node.js, tous les clients s'exécutent sur le même thread (ils peuvent même partager les mêmes variables!) Je comprends que les opérations d'E / S sont basées sur des événements afin de ne pas bloquer la boucle de thread principale.

Ce que je ne comprends pas, c'est POURQUOI l'auteur de Node l'a choisi pour être monothread? Cela rend les choses difficiles. Par exemple, je ne peux pas exécuter une fonction gourmande en processeur car elle bloque le thread principal (et les nouvelles demandes des clients sont bloquées), j'ai donc besoin de générer un processus (ce qui signifie que je dois créer un fichier JavaScript séparé et exécuter un autre processus de nœud sur il). Cependant, en PHP, les tâches intensives du processeur ne bloquent pas les autres clients car, comme je l'ai mentionné, chaque client est sur un thread différent. Quels sont ses avantages par rapport aux serveurs Web multi-threads?

Remarque: J'ai utilisé le clustering pour contourner ce problème, mais ce n'est pas joli.

Node.js a été créé explicitement comme une expérience de traitement asynchrone. La théorie était que le traitement asynchrone sur un seul thread pouvait fournir plus de performances et d'évolutivité sous des charges Web typiques que l'implémentation basée sur un thread typique.

Et tu sais quoi? À mon avis, cette théorie a été confirmée. Une application node.js qui ne fait pas de tâches gourmandes en CPU peut exécuter des milliers de connexions simultanées de plus qu'Apache ou IIS ou d'autres serveurs basés sur des threads.

La nature asynchrone à un seul fil rend les choses compliquées. Mais pensez-vous honnêtement que c'est plus compliqué que d'enfiler? Une condition de course peut ruiner tout votre mois! Ou videz votre pool de threads en raison d'un paramètre quelque part et regardez votre temps de réponse lent à une analyse! Sans parler des blocages, des inversions de priorité et de toutes les autres girations associées au multithreading.

En fin de compte, je ne pense pas que ce soit universellement meilleur ou pire; c'est différent, et parfois c'est mieux et parfois non. Utilisez le bon outil pour le travail.

Le problème avec le modèle «un thread par demande» pour un serveur est qu'ils ne s'adaptent pas bien pour plusieurs scénarios par rapport au modèle de thread de boucle d'événements.

En règle générale, dans les scénarios intensifs d'E / S, les demandes passent la plupart du temps à attendre la fin des E / S. Pendant ce temps, dans le modèle "un thread par requête", les ressources liées au thread (comme la mémoire) sont inutilisées et la mémoire est le facteur limitant. Dans le modèle de boucle d'événement, le thread de boucle sélectionne l'événement suivant (E / S terminé) à gérer. Le thread est donc toujours occupé (si vous le programmez correctement bien sûr).

Le modèle de boucle d'événement, comme toutes les nouvelles choses, semble brillant et la solution à tous les problèmes, mais le modèle à utiliser dépendra du scénario que vous devez aborder. Si vous avez un scénario d'E / S intensif (comme un proxy), le modèle de base d'événements régnera, tandis qu'un scénario gourmand en CPU avec un faible nombre de processus simultanés fonctionnera mieux avec le modèle basé sur les threads.

Dans le monde réel, la plupart des scénarios seront un peu au milieu. Vous devrez équilibrer le besoin réel d'évolutivité avec la complexité du développement pour trouver l'architecture correcte (par exemple, disposer d'un frontend de base d'événements qui délègue au backend pour les tâches gourmandes en CPU. Le front end utilisera peu de ressources en attente de la tâche) Comme pour tout système distribué, il faut un certain effort pour le faire fonctionner.

Si vous recherchez la balle d'argent qui s'adaptera à n'importe quel scénario sans aucun effort, vous vous retrouverez avec une balle dans votre pied.

Pour faire court, le nœud s'inspire de la V8, qui est un filetage interne unique. Il existe des moyens de contourner les contraintes des tâches gourmandes en ressources processeur.

À un moment donné (0,7), les auteurs ont essayé d'introduire des isolats comme moyen d'implémenter plusieurs threads de calcul, mais ont finalement été supprimés: https://groups.google.com/forum/#!msg/nodejs/zLzuo292hX0/F7gqfUiKi2sJ