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


62

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?


9
Je peux voir que cette question est fermée en tant qu'opinion. Je ne suis absolument pas d'accord. Question "Que peut faire Nginx pour lequel uWSGI ne peut pas?" est basé sur les faits.
user983447

1
Je ne parle généralement pas en faveur de la réouverture, mais dans ce cas, je suis d'accord. La réponse existante, votée et acceptée, est bonne, ce qui montre que la question, telle qu’elle est écrite, admet des réponses sensées et pertinentes; Je pense que cela en fait probablement une bonne question.
MadHatter

Réponses:


55

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.


3
La seule chose qui me vienne à l’esprit et qui, à mon avis, mérite d’être soulignée, est que le protocole natif de uWSGI n’est pas http mais le protocole uwsgi. Le protocole uwsgi est plus simple et plus efficace à traiter que le protocole http. Par conséquent, le fait de placer un serveur Web plus complet (nginx ou autre) devant votre application uWSGI ne permet pas de dupliquer beaucoup de traitement et peut offrir des avantages significatifs en fonction de vos besoins. Besoins.
Håkan Lindqvist Le

@ HåkanLindqvist est absolument correct; Pour clarifier, uWSGI est tout à fait capable de "parler" HTTP, cependant, peut donc se débrouiller tout seul, mais oui, il est bon de noter qu’un serveur Web devant utiliserait le protocole uwsgi, et non HTTP, parler à uWSGI, et donc, oui, très peu de duplication du traitement impliqué.
Kromey

C'est une bonne réponse, cependant, elle pourrait être améliorée avec un lien vers la propre documentation d'uWSGI sur le sujet, qui explique plus précisément ce que vous pouvez faire avec uWSGI: uwsgi-docs.readthedocs.io/en/latest/…
Tobias McNulty

1

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.


1
Je doute que l’utilisation de Nginx puisse changer cela. Lorsqu'une application Django est hébergée sur Apache à l'aide de WSGI, la fonction d'affichage est appelée avant que toute donnée POST ne soit lue à partir d'un socket. Ainsi, si le client est lent, il occupera un fil à partir de la demande reçue jusqu'à la réception des données POST. Pourquoi remplacer Apache par Nginx changerait-il cela?
Kasperd

1
Comme je le sais, par défaut, Nginx n’exécutera pas la requête HTTP sur le serveur d’application backend tant qu’il n’aura pas reçu une requête HTTP complète. Ainsi, pour les serveurs d’applications tels que Django, ils obtiennent toujours une connexion et une requête HTTP rapides, sans perdre de temps à attendre une requête http complète. Après avoir traité la quête bientôt, le thread en cours d’exécution pourrait être inactif pour la prochaine requête HTTP.
jeudi

1
C'est ce qu'on appelle la mise en mémoire tampon des demandes, qui est activée par défaut dans Nginx (dans les anciennes versions de Nginx, il n'était pas possible de désactiver cette option
Tobias McNulty
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.