Pourquoi ai-je besoin de nginx quand j'ai uWSGI
Il existe de nombreux tutoriels sur la façon de configurer nginx pour coopérer avec uWGSI lorsque je souhaite déployer l'application Django.
Mais pourquoi ai-je besoin de nginx dans ce kit? uWSGI lui-même peut servir WSGI Python, il peut servir des fichiers statiques, il peut aussi faire du SSL. Que peut faire nginx ce que uWSGI ne peut pas?
Vous ne le faites 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 comme nginx existent depuis plus longtemps et sont (probablement de toute façon) plus sécurisés, ainsi que des fonctionnalités supplémentaires non prises en charge par uWSGI - par exemple, une meilleure gestion des ressources statiques (via toute combinaison de Expires ou E-Tag en-têtes, compression gzip, gzip précompressé, etc.) qui peuvent réduire considérablement la charge du serveur et du réseau; en outre, un serveur comme nginx devant votre application Django peut également implémenter la mise en cache de votre contenu dynamique, ce qui contribue à réduire davantage la charge du serveur et même à faciliter l'utilisation d'un CDN (qui vous ne pouvez pas aller plus loin et avoir nginx sur un serveur complètement séparé, inverser les demandes de proxy pour le contenu dynamique vers un cluster de serveurs d'applications à charge équilibrée tout en gérant le contenu statique lui-même.
Par exemple, mon blog (alors qu'il est WordPress, il a nginx en face de lui) est réglé pour mettre en cache les publications pendant 24 heures et pour mettre en cache les pages d'index pendant 5 minutes; Bien que je ne vois pas assez de trafic pour que cela ait vraiment de l'importance la plupart du temps, cela aide mon petit VPS minuscule à résister à la poussée occasionnelle qui pourrait autrement le faire tomber - comme la forte augmentation du trafic lorsqu'un de mes articles a été choisi par un Twitterer avec plusieurs milliers de followers, dont beaucoup l'ont re-tweeté à leurs milliers de followers.
Si j'avais exécuté un serveur uWSGI "nu" (et en supposant qu'il s'agissait d'un site Django, plutôt que WordPress), il aurait peut-être bien résisté - ou il aurait pu s'est écrasé et brûlé, me coûtant en visiteurs manqués. Avoir nginx devant pour gérer cette charge peut vraiment aider.
Cela étant dit, si vous exécutez simplement un petit site qui ne verra pas beaucoup de trafic, il n'y a pas vraiment besoin de nginx ou autre chose - 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 encore voudrez peut-être uWSGI, mais vous devriez au moins envisager quelque chose devant pour aider à la charge. En fait, vous devriez vraiment tester différentes configurations de charge avec votre site fini pour déterminer ce qui fonctionne le mieux pour vous sous votre charge attendue, et utiliser tout ce qui finira par être.
OMI, si vous mettez votre site Web sur Internet au lieu de Lab, vous pourriez voir la différence.
Imaginez un utilisateur d'un autre pays avec un navigateur Web ouvert à faible vitesse réseau pour accéder à votre site Web. uWSGI gérera cette connexion Http dans un thread. Ce thread peut attendre assez longtemps pour attendre une demande Http complète en raison de la faible vitesse du réseau. Si la taille de votre pool de threads est de 100, imaginez 100 utilisateurs aussi lents, que se passera-t-il? Aucun thread inactif pour gérer les autres requêtes Http.
Mais les choses sont bien différentes pour Nginx. Nginx est conçu en "modèle de réacteur". Vous pouvez google 'Reactor Pattern' pour voir comment cela fonctionne. En bref, une connexion à faible vitesse ne l'affecte pas pour gérer d'autres demandes Http.