Pourquoi Node.js est-il en thread unique ?

Question

Sur les serveurs web basés sur PHP (ou Java/ASP.NET/Ruby), chaque requête 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 du thread principal.

Ce que je ne comprends pas, c'est POURQUOI l'auteur de Node l'a choisi à thread unique? Cela complique les choses. Par exemple, je ne peux pas exécuter une fonction intensive en CPU car cela bloque le thread principal (et de nouvelles requêtes clients sont bloquées), donc je dois créer un processus (ce qui signifie que je dois créer un fichier JavaScript séparé et exécuter un autre processus Node dessus). Cependant, avec PHP, les tâches intensives en CPU 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-threadés?

Remarque : J'ai utilisé le clustering pour contourner cela, mais ce n'est pas élégant.

Answer 1

Node.js a été créé explicitement comme une expérience dans le traitement asynchrone. La théorie était que le traitement asynchrone sur un seul thread pourrait offrir plus de performances et de scalabilité sous des charges web typiques que la mise en œuvre basée sur des threads typiques.

Et vous savez quoi ? À mon avis, cette théorie s'est avérée vraie. Une application node.js qui ne fait pas des tâches intensives en CPU peut exécuter des milliers de connexions concurrentes de plus qu'Apache, IIS ou d'autres serveurs basés sur des threads.

La nature asynchrone monofilaire rend les choses compliquées. Mais pensez-vous honnêtement que c'est plus compliqué que le threading ? Une condition de course peut ruiner tout votre mois ! Ou vider votre pool de threads en raison de certains paramètres quelque part et regarder votre temps de réponse ralentir à ramper ! Sans parler des impasses, des inversions de priorité et de toutes les autres acrobaties lié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 ce n'est pas le cas. Utilisez le bon outil pour le travail.

Answer 2

Le problème avec le modèle "un thread par requête" pour un serveur est qu'ils ne s'adaptent pas bien à plusieurs scénarios comparativement au modèle de thread de boucle d'événement.

Typiquement, dans les scénarios intensifs en E/S, les requêtes passent la plupart du temps à attendre que les E/S se terminent. Pendant ce temps, dans le modèle "un thread par requête", les ressources liées au thread (comme la mémoire) ne sont pas utilisées et la mémoire est le facteur limitant. Dans le modèle de boucle d'événement, le thread de la boucle sélectionne le prochain événement (E/S terminée) à traiter. Ainsi, le thread est toujours occupé (si vous le programmez correctement bien sûr).

Le modèle de boucle d'événement, comme toutes les nouveautés, semble brillant et la solution à tous les problèmes, mais le choix du modèle dépendra du scénario que vous devez aborder. Si vous avez un scénario intensif en E/S (comme un proxy), le modèle basé sur les événements sera la meilleure solution, alors qu'un scénario intensif en CPU avec un faible nombre de processus en parallèle fonctionnera mieux avec le modèle basé sur les threads.

Dans le monde réel, la plupart des scénarios seront un peu entre les deux. Vous devrez trouver un équilibre entre le réel besoin de scalabilité et la complexité de développement pour trouver l'architecture correcte (par exemple, avoir un avant-poste basé sur des événements qui délègue les tâches intensives en CPU à l'arrière-plan. L'avant-poste utilisera peu de ressources en attendant le résultat de la tâche.) Comme avec tout système distribué, cela demande un certain effort pour le faire fonctionner.

Si vous cherchez la solution miracle qui conviendra à n'importe quel scénario sans aucun effort, vous finirez par vous tirer une balle dans le pied.

Answer 3

En résumé, node s'inspire de V8, qui est interne unithread. Il existe des moyens de contourner les contraintes pour les tâches intensives en CPU.

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