Il existe de nombreux tutoriels sur la façon de configurer nginx pour coopérer avec uWGSI lorsque je veux déployer une application Django.
Mais pourquoi ai-je besoin de nginx dans ce kit ? uWSGI lui-même peut servir des applications WSGI Python, il peut servir des fichiers statiques, il peut aussi faire du SSL. Que peut faire nginx que uWSGI ne peut pas faire ?
Tu ne le fais pas.
C'est la réponse la plus simple, de toute façon tu n'as pas besoin de uWSGI est lui-même un serveur performant.
Cependant, d'autres serveurs comme nginx existent depuis plus longtemps et sont (probablement, en tout cas) plus sûrs, tout en disposant de fonctionnalités supplémentaires non prises en charge par uWSGI -- par exemple, une meilleure gestion des ressources statiques (via toute combinaison d'en-têtes Expires ou E-Tag, compression gzip, gzip pré-compressé, etc. ) qui peut réduire de manière significative la charge du serveur et du réseau ; en outre, un serveur comme nginx devant votre application Django peut également mettre en œuvre la mise en cache de votre contenu dynamique, contribuant ainsi à réduire la charge du serveur, et même à faciliter l'utilisation d'un CDN (qui n'est normalement pas adapté au contenu dynamique). Vous pouvez même aller plus loin et avoir nginx sur un serveur complètement séparé, qui renvoie les demandes de contenu dynamique vers un cluster de serveurs d'application à charge équilibrée tout en gérant le contenu statique lui-même.
Par exemple, mon blog (bien qu'il s'agisse de WordPress, il est précédé de nginx) est réglé pour mettre en cache les articles pendant 24 heures et les pages d'index pendant 5 minutes. Même si le trafic n'est pas suffisant pour que cela ait une réelle importance la plupart du temps, cela aide mon tout petit VPS à faire face à l'augmentation occasionnelle du trafic qui pourrait autrement le faire tomber -- comme la grande augmentation du trafic lorsque l'un de mes articles a été repris par un Twitterer ayant plusieurs milliers de followers, dont beaucoup l'ont re-tweeté à leurs milliers de followers.
Si j'avais utilisé un serveur uWSGI "nu" (et en supposant qu'il s'agissait d'un site Django, plutôt que WordPress), il aurait pu résister sans problème - ou bien il aurait pu se planter et brûler, ce qui m'aurait coûté en visiteurs manqués. Le fait d'avoir nginx en face de lui pour gérer cette charge peut vraiment aider.
Tout cela étant dit, si vous ne gérez qu'un petit site qui ne connaîtra pas un trafic important, vous n'avez pas vraiment besoin de nginx ou de quoi que ce soit d'autre - utilisez simplement uWSGI si c'est ce que vous voulez faire. D'un autre côté, si vous voyez beaucoup de trafic... et bien, vous... toujours Vous pourriez vouloir uWSGI, mais vous devriez au moins envisager de placer quelque chose devant lui pour l'aider à supporter la charge. En fait, vous devriez vraiment tester différentes configurations avec votre site fini afin de déterminer ce qui fonctionne le mieux pour vous en fonction de la charge prévue, et utiliser ce qui en ressort.
IMO, si vous mettez votre site web dans Internet au lieu de Lab, vous verrez peut-être la différence.
Imaginez qu'un utilisateur d'un autre pays avec un réseau à faible vitesse ouvre un navigateur web pour accéder à votre site web. uWSGI va gérer cette connexion Http dans un thread. Ce thread peut passer un temps assez long à attendre une requête Http complète en raison de la faible vitesse du réseau. Si votre pool de threads est de 100, imaginez 100 utilisateurs aussi lents, que se passera-t-il ? Aucun thread libre pour traiter les autres demandes Http.
Mais les choses sont bien différentes pour Nginx. Nginx est conçu selon le 'Reactor Pattern'. Vous pouvez chercher sur Google "Reactor Pattern" pour voir comment il fonctionne. En bref, une connexion à faible débit ne l'empêche pas de traiter d'autres demandes Http.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
