node.js lui-même ou frontend nginx pour servir des fichiers statiques?
Existe-t-il une référence 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 servez les fichiers statiques en l'utilisant?
la solution nginx semble être plus gérable pour moi, des pensées?
Je devrai être en désaccord avec les réponses ici. Alors que Node fera l'affaire, nginx sera certainement plus rapide lorsqu'il sera configuré correctement. Nginx est implémenté efficacement en C suivant un modèle similaire (ne retournant à une connexion qu'en cas de besoin) avec une petite empreinte mémoire. De plus, il prend en charge le sendfile syscall pour servir ces fichiers aussi rapidement que possible pour servir les fichiers, car c'est le noyau du système d'exploitation lui-même qui fait le travail.
À présent, nginx est devenu la norme de facto en tant que serveur frontal. Vous pouvez l'utiliser pour ses performances en servant des fichiers statiques, gzip, SSL et même l'équilibrage de charge plus tard.
P.S .: Cela suppose que les fichiers sont vraiment "statiques" comme au repos sur le disque au moment de la demande.
J'ai fait un rapide ab -n 10000 -c 100 pour servir un 1406 octet statique 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 + static middleware (plus lent):
J'ai une interprétation différente des graphiques de @ gremo. Il me semble que le nœud et l'échelle nginx ont le même nombre de demandes (entre 9 et 10 000). Bien sûr, la latence de la réponse pour nginx est inférieure de 20 ms, mais je ne pense pas que les utilisateurs percevront nécessairement cette différence (si votre application est bien conçue). Étant donné un nombre fixe de machines, il faudrait une charge assez importante avant de convertir une machine de nœud en nginx, étant donné que le nœud est l'endroit où la majeure partie 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 servir 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 du 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 que mon frontend Nginx serve des actifs statiques dans la plupart des cas, dans ce
1) Le projet doit maintenant être sur la même machine - ou doit être divisé en actifs (sur la machine nginx) et application web (sur plusieurs machines pour la mise à l'échelle)
2) La configuration Nginx doit maintenant conserver 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 à ngingx lors du service de fichiers statiques).
Les performances en matière de service de fichiers statiques se résument souvent à plus que le simple serveur Web effectuant le travail. Si vous souhaitez obtenir 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 Edge.
Si cela ne vous inquiète pas, le nœud 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 de blocage peut bloquer l'ensemble du processus et dégrader les performances de vos applications. Il est fort probable que vous soyez écrire votre code de manière non bloquante, mais si vous faites quoi que ce soit de manière synchrone, vous pouvez provoquer un blocage, ce qui dégraderait la vitesse à laquelle d'autres clients peuvent obtenir leurs fichiers statiques servis. La solution simple est de ne pas écrire de code de blocage, mais parfois c'est pas une possibilité, ou vous ne pouvez pas toujours l'appliquer.