Existe-t-il un point de repère ou une comparaison plus rapide: placez nginx devant le nœud et laissez-le servir directement les fichiers statiques ou utilisez uniquement le nœud et diffusez les fichiers statiques en l'utilisant?
La solution nginx semble être plus gérable pour moi, des pensées?
Réponses:
Je vais devoir être en désaccord avec les réponses ici. Alors que Node fonctionnera bien, nginx sera certainement plus rapide lorsqu'il est configuré correctement. nginx est implémenté efficacement en C suivant un modèle similaire (retour à une connexion uniquement lorsque cela est nécessaire) avec une petite empreinte mémoire. De plus, il prend en charge la sendfile syscall pour servir ces fichiers qui est aussi vite que vous pouvez éventuellement obtenir au service de fichiers, car il est le noyau du système d'exploitation lui - même qui est de faire le travail.
Désormais, nginx est devenu le standard de facto en tant que serveur frontal. Vous pouvez l'utiliser pour ses performances dans la diffusion de fichiers statiques, gzip, SSL et même l'équilibrage de charge plus tard.
PS: Cela suppose que les fichiers sont vraiment "statiques" comme au repos sur le disque au moment de la requête.
sendfile- mais il semble que vous deviez écrire du code, voir par exemple. blog.std.in/2010/09/09/using-sendfile-with-nodejs
J'ai fait un rapide ab -n 10000 -c 100pour servir un octet statique de 1406 favicon.ico, en comparant nginx, Express.js (middleware statique) et Express.js en cluster. J'espère que cela t'aides:
Malheureusement, je ne peux pas tester 1000 ou même 10000 requêtes simultanées car nginx, sur ma machine, commencera à générer des erreurs.
EDIT : comme suggéré par artvolk, voici les résultats du cluster + staticmiddleware (plus lent):
staticmiddleware de mise en cache en production.
J'ai une interprétation différente des graphiques de @ gremo. Il me semble que les nœuds et les nginx sont mis à l'échelle avec le même nombre de requêtes (entre 9-10k). Bien sûr, la latence de la réponse pour nginx est inférieure d'une constante de 20 ms, mais je ne pense pas que les utilisateurs percevront nécessairement cette différence (si votre application est bien construite). Étant donné un nombre fixe de machines, il faudrait une quantité assez importante de charge avant de convertir une machine à nœuds en nginx, étant donné que ce nœud est l'endroit où la plupart de la charge se produira en premier lieu. Le seul contrepoint à cela est si vous dédiez déjà une machine à nginx pour l'équilibrage de charge. Si tel est le cas, vous pouvez également le faire diffuser votre contenu statique.
Quoi qu'il en soit, je configurerais Nginx pour mettre en cache les fichiers statiques ... vous verrez une énorme différence là-bas. Ensuite, que vous les serviez à partir d'un nœud ou non, vous obtenez essentiellement les mêmes performances et le même allégement de charge sur votre application de nœud.
Personnellement, je n'aime pas l'idée de mon frontend Nginx servant des actifs statiques dans la plupart des cas, en ce sens
1) Le projet doit maintenant être sur la même machine - ou doit être divisé en actifs (sur une machine nginx) et application Web (sur plusieurs machines pour la mise à l'échelle)
2) La configuration de Nginx doit maintenant maintenir les emplacements des chemins pour les actifs statiques / recharger lorsqu'ils changent.
C'est une question délicate à répondre. Si vous avez écrit un serveur de nœuds vraiment léger pour ne servir que des fichiers statiques, il fonctionnerait probablement mieux que nginx, mais ce n'est pas si simple. ( Voici un "benchmark" comparant un serveur de fichiers nodejs et lighttpd - dont les performances sont similaires à celles de ngingx lors du service de fichiers statiques).
Les performances en ce qui concerne la diffusion de fichiers statiques ne se limitent pas au serveur Web qui effectue le travail. Si vous voulez les meilleures performances possibles, vous utiliserez un CDN pour servir vos fichiers afin de réduire la latence pour les utilisateurs finaux et bénéficier de la mise en cache périphérique.
Si cela ne vous inquiète pas, node peut très bien servir des fichiers statiques dans la plupart des situations. Node se prête au code asynchrone, sur lequel il s'appuie également car il est monothread et toute entrée / sortie bloquante peut bloquer l'ensemble du processus et dégrader les performances de vos applications. Il est plus que probable que vous écrivez votre code de manière non bloquante, mais si vous faites quelque chose de manière synchrone, vous pouvez provoquer un blocage, ce qui dégraderait la vitesse à laquelle les autres clients peuvent obtenir leurs fichiers statiques. La solution simple est de ne pas écrire de code de blocage, mais parfois ce n'est pas une possibilité, ou vous ne pouvez pas toujours l'appliquer.
Je suis certain que purement node.js peut surpasser nginx à bien des égards.
Tous ont dit que je devais rester NginX a un cache intégré, alors que node.js n'est pas livré avec celui-ci installé en usine (VOUS DEVEZ CRÉER VOTRE PROPRE CACHE DE FICHIERS). Le cache de fichiers personnalisé surpasse nginx et tout autre serveur du marché car il est super simple.
Nginx fonctionne également sur plusieurs cœurs. Pour utiliser tout le potentiel de Node, vous devez mettre en cluster des serveurs de nœuds. Si vous souhaitez savoir comment faire, veuillez pm.
Vous avez besoin de creuser profondément pour atteindre le nirvana des performances avec le nœud, c'est le seul problème. Une fois fait bon sang ouais ... ça bat Nginx.