Pour être honnête, je n’ai pas encore tout compris - et j’ai même compris le fonctionnement de node.js, en tant que thread unique utilisant le modèle d’événement. Je ne comprends tout simplement pas en quoi cela est meilleur qu'Apache et comment il évolue horizontalement s'il s'agit d'un thread unique.
Réponses
Trop de publicités?
Bart Verkoeijen
Points
1567
J'ai trouvé que ce billet de blog par Tomislav Acaap l'explique très bien:
Pourquoi Diable Voudrais-Je Utiliser Node.js? Un Cas-par-Cas d'Introduction
Mon interprétation de l'essentiel, pour le Nœud de 0,10, par rapport à Apache:
Les bonnes parties
- Node.js évite de se servir de threads pour chaque demande, ou n'a pas besoin de gérer la mise en commun des demandes à un ensemble de threads comme Apache. Il a donc moins de frais généraux pour gérer les requêtes, et excelle à répondre rapidement.
- Node.js peut déléguer l'exécution de la demande à un autre composant, et de se concentrer sur les nouvelles demandes jusqu'à ce que les délégués composant retourne avec le résultat du traitement. C'est le code asynchrone, et est rendue possible par le concours complet d'équitation modèle. Apache s'exécute demandes en série à l'intérieur d'une piscine, et ne peut pas réutiliser le fil lorsque l'un de ses modules est simplement en attente pour une tâche à accomplir. Apache va ensuite la file d'attente de demandes jusqu'à ce qu'un thread dans la piscine devient de nouveau disponible.
- Node.js les pourparlers de JavaScript et est donc très rapide en passant par et de manipuler du JSON (extrait de web externe de l'API de sources telles que MongoDB, tout en réduisant le temps nécessaire à chaque demande. Les modules Apache, PHP, peut-être besoin de plus de temps, car ils ne peuvent pas efficacement analyser et de manipuler du JSON parce qu'ils ont besoin de triage pour traiter les données.
Les mauvaises parties
Remarque: la plupart des mauvaises pièces énumérées ci-dessous seront améliorées avec la prochaine version 0.12, quelque chose à garder au courant.
- Node.js suce au calcul intensif tâches, parce que chaque fois qu'il fait quelque chose de long en cours d'exécution, il mettra en file d'attente tous les autres demandes entrantes, en raison de son seul thread. Apache, ont généralement plus de threads disponibles, et le système d'exploitation proprement et de façon équitable calendrier de temps PROCESSEUR entre ces fils, tout en permettant aux nouveaux sujets à traiter, mais un peu plus lent. Sauf lorsque tous les threads disponibles dans Apache sont la gestion des demandes, Apache va également démarrer des files d'attente des demandes.
- Node.js ne pas utiliser pleinement les Processeurs multi-core, à moins de faire un Node.js cluster ou d'accélération des processus enfants. Ironiquement, si vous ne les deux derniers, vous pouvez ajouter plus d'orchestration de la surcharge de travail, le même problème de Apache. Logiquement, vous pouvez également faire tourner plus Node.js processus, mais ce n'est pas géré par Node.js. Vous devez tester votre code pour voir ce qui fonctionne le mieux; 1) le multi-threading de l'intérieur Node.js avec les clusters et les processus enfants, ou 2) plusieurs Node.js les processus.
Mesures d'atténuation
Toutes les plates-formes de serveur ont une limite supérieure. Node.js et Apache deux va l'atteindre à un certain point.
- Node.js permettra d'atteindre les plus rapides quand vous avez des tâches de calcul.
- Apache va l'atteindre de la manière la plus rapide lorsque l'on jette des tonnes de petites demandes qui exigent une exécution en série.
Trois choses que vous pourriez faire à l'échelle du débit de Node.js
- Utiliser les Processeurs multi-core, par la mise en place d'un cluster, l'utilisation de processus enfant, ou de l'utilisation d'un multi-processus orchestrator comme Phusion Passenger.
- Configuration des rôles de travail connecté avec un message de la file d'attente. Ce sera la solution la plus efficace contre de calcul intensif à long demandes en cours d'exécution hors de la charge à un travailleur de la ferme. Cela permettra de séparer vos serveurs en deux parties: 1) face au public de bureau les serveurs qui acceptent les demandes des utilisateurs, et 2) les travailleurs des serveurs de traitement des longues tâches en cours d'exécution. Les deux sont reliés par un message de la file d'attente. Les employés de bureau les serveurs d'ajouter des messages (entrants long demandes en cours d'exécution) de la file d'attente. Le travailleur rôles écouter les messages entrants, poignée de ceux-ci, et peut retourner le résultat dans la file d'attente de messages. Si la requête/réponse est nécessaire, alors l'écriture serveur de manière asynchrone d'attendre le message de réponse d'arriver dans la file d'attente de messages. Exemples de files d'attente de messages sont RabbitMQ et ZeroMQ.
- Configuration de l'équilibreur de charge et de spin plus de serveurs. Maintenant que vous utiliser efficacement le matériel et déléguer les tâches longues, vous pouvez l'échelle horizontale. Si vous avez un équilibreur de charge, vous pouvez ajouter plus de bureau les serveurs. À l'aide d'une file d'attente de message, vous pouvez ajouter d'autres serveurs worker. Vous pouvez même le configurer dans le nuage de sorte que vous pouvez adapter à la demande.
Kevin Lee
Points
216
Il dépend de la façon dont vous l'utilisez. Node.js est mono-thread par défaut, mais à l'aide de la (relativement) nouveau cluster module, vous pouvez mettre à l'échelle horizontalement sur plusieurs threads.
En outre, votre base de données doit également dicter la façon efficace de mise à l'échelle est avec nœud. Par exemple, l'utilisation de MySQL avec node.js vous n'obtiendrez pas à peu près autant d'avantages que l'utilisation de MongoDB, en raison de l'événement piloté par la nature des deux MongoDB et node.js.
Le lien suivant a beaucoup de bons repères de systèmes avec des configurations différentes: http://www.techempower.com/benchmarks/
Node.js n'a pas le rang le plus élevé, mais par rapport à d'autres configurations à l'aide de nginx (pas apache sur leurs tables, mais assez proche), il le fait plutôt bien.
Encore une fois cependant, il dépend fortement de vos besoins. Je crois que si vous êtes simplement de servir de sites web statiques, il est conseillé de vous en tenir à une approche plus traditionnelle de la pile. Cependant les gens ont fait des choses incroyables avec node.js pour d'autres besoins: http://blog.caustik.com/2012/08/19/node-js-w1m-concurrent-connections/ (c10k? ha!)
Edit: Il vaut la peine de mentionner que vous avez vraiment ne sont pas "remplacer" juste apache avec node.js. Vous serait de remplacer apache ET php (typiques de la pile lamp).
