Pourquoi ai-je besoin de nginx quand j'ai uWSGI

Il existe de nombreux tutoriels sur la façon de configurer nginx pour qu'il coopère avec uWGSI lorsque je souhaite déployer une application Django.

Mais pourquoi ai-je besoin de nginx dans ce kit? uWSGI peut servir des applications WSGI Python, des fichiers statiques, SSL. Que peut faire Nginx pour lequel uWSGI ne peut pas?

Vous pas.

C'est la réponse simple, de toute façon - vous n'en avez pas besoin . uWSGI est lui-même un serveur capable.

Cependant, d’autres serveurs tels que nginx existent depuis plus longtemps et sont (probablement, en tout cas) plus sécurisés, tout en offrant des fonctionnalités supplémentaires non prises en charge par uWSGI - par exemple, une gestion améliorée des ressources statiques (via une combinaison quelconque de Expires ou de E-Tag). en-têtes, compression gzip, gzip pré-compressé, etc.) pouvant réduire considérablement la charge du serveur et du réseau; de plus, un serveur comme nginx devant votre application Django peut également mettre en cache votre contenu dynamique, contribuant ainsi à réduire la charge du serveur et facilitant même l'utilisation d'un CDN (qui ne fonctionne normalement pas bien avec le contenu dynamique). ). Vous pouvez même aller plus loin et avoir nginx sur un serveur complètement séparé, en inversant les requêtes de contenu dynamique pour un contenu dynamique vers un cluster de serveurs d’application équilibré en charge, tout en gérant le contenu statique lui-même.

Par exemple, mon blog (alors qu’il s’agit de WordPress, nginx se trouve en face de celui-ci) est paramétré pour mettre en cache les publications pendant 24 heures et pour mettre en cache les pages d’index pendant 5 minutes; alors que je ne vois pas assez de trafic pour que cela compte vraiment la plupart du temps, cela aide mon petit petit VPS à faire face à une poussée occasionnelle qui pourrait sinon la renverser - telle que la forte poussée de trafic lorsqu'un de mes articles a été sélectionné par un Twitterer avec plusieurs milliers d'adeptes, dont beaucoup ont re-tweeté à leurs milliers d'adeptes.

Si j'avais utilisé un serveur uWSGI "nu" (et en supposant qu'il s'agisse d'un site Django plutôt que WordPress), il aurait peut-être bien résisté - ou il s'est peut-être écrasé et brûlé, ce qui m'a coûté en visiteurs manqués . Avoir nginx devant lui pour gérer cette charge peut vraiment aider.

Ceci étant dit, si vous utilisez simplement un petit site ne générant pas beaucoup de trafic, nginx ou tout autre élément n'est pas vraiment nécessaire - utilisez simplement uWSGI seul si c'est ce que vous voulez faire. D'un autre côté, si vous voyez beaucoup de trafic ... eh bien, vous voudrez peut-être toujours utiliser uWSGI, mais vous devriez au moins penser à quelque chose devant pour l'aider à supporter le chargement. En fait, vous devriez vraiment tester en charge différentes configurations avec votre site fini afin de déterminer ce qui fonctionne le mieux pour vous, compte tenu de votre charge prévisionnelle, et d'utiliser ce que vous voudrez.

OMI, si vous mettez votre site Web dans Internet au lieu de Lab, vous verrez peut-être la différence.

Imaginez un utilisateur d'un autre pays avec une vitesse de réseau faible et un navigateur Web ouvert pour accéder à votre site Web. uWSGI gérera cette connexion Http dans un thread. Ce thread peut passer beaucoup de temps à attendre une requête HTTP complète en raison de la faible vitesse du réseau. Si la taille de votre pool de threads est de 100, imaginez que 100 utilisateurs soient lents, que se passera-t-il? Pas de thread inactif pour gérer une autre requête Http.

Mais les choses sont assez différentes pour Nginx. Nginx est conçu dans le «modèle de réacteur». Vous pouvez google 'Pattern Reactor' pour voir comment cela fonctionne. En bref, la connexion à faible vitesse ne l’affecte pas pour le traitement des autres requêtes HTTP.