WSGI vs uWSGi avec Nginx [fermé]

Quelqu'un pourrait-il expliquer les avantages / inconvénients lors de l'utilisation de WSGI VS uWSGI avec Nginx.

Actuellement, je suis en train de créer un serveur de production pour le site Web de Django que j'ai préparé mais je n'arrive pas à décider si je dois utiliser WSGI ou uWSGI. Pouvez-vous expliquer en détail ce qui différencie chaque configuration? Quelle configuration doit être la mieux adaptée?

Merci d'avance

— peur_matrix
source

Cet article de blog est une comparaison très détaillée de beaucoup de serveurs Python WSGI, avec un résumé et quelques recommandations à la fin.

— Lowe Thiderman

Et utilise également des configurations pour certains serveurs qui sont vraiment douteuses et les font paraître pires qu'elles ne peuvent l'être. Il faut faire attention à ce que l'on lit dans cette comparaison.

— Graham Dumpleton

WSGI est une spécification. uWSGI fournit une implémentation de la spécification WSGI. Vous ne pouvez pas les comparer. Vous ne pouvez comparer que différentes implémentations.

— Graham Dumpleton

Réponses:

101

Ok, les gars, cette confusion est due au manque de détails de plusieurs sources, à la dénomination de ces protocoles et à ce qu'est réellement WSGI.

Sommaire:

WSGI et uwsgi sont tous deux des protocoles ARE , pas des serveurs. Il est utilisé pour communiquer avec les serveurs Web pour l'équilibrage de charge et surtout pour profiter de fonctionnalités supplémentaires que le HTTP pur ne peut pas fournir. Jusqu'à présent, Nginx et Cherokee ont implémenté ce protocole.
uWSGI est un serveur et l'un des protocoles qu'il implémente est WSGI (ne confondez pas le protocole uwsgi avec le serveur uWSGI). WSGI est une spécification Python . Il existe plusieurs implémentations de la spécification WSGI et elle est destinée à être utilisée pour plus que de simples serveurs d'applications / serveurs Web, mais il existe un certain nombre de serveurs d'applications WSGI (par exemple CherryPy, qui possède également un serveur Web compatible WSGI prêt pour la production , si vous n'étiez pas déjà assez confus!).
Comparer uwsgi à WSGI, c'est comparer des oranges à des pommes.

— Derek Litz
source

Typo: "1. uwsgi est un protocole pas un serveur." -> "1. WSGI est un protocole pas un serveur."

— Aman

En fait, ce que j'ai écrit pour 1 est correct, mais c'est vrai que WSGI est un protocole ainsi que uwsgi, donc les deux déclarations que vous avez écrites sont correctes :). Bien sûr, sans le reste du contexte de 1. C'est le protocole utilisé par le serveur uWSGI. wiki.nginx.org/HttpUwsgiModule , - "Ne confondez pas le protocole uwsgi avec le serveur uWSGI (qui parle le protocole uwsgi)"

— Derek Litz

Ah ok. J'avais pensé que vous essayiez de faire un contraste entre la déclaration 1. "wsgi est un protocole .." et 2. "uwsgi est un serveur qui implémente le protocole".

— Aman

@DerekLitz, Sur quels serveurs django fonctionne quand nous le faisons python manage.py runserver?

— Piyush S.Wanare

python manage.py runserverest un serveur interne intégré à Django. Ce n'est pas Apache, Nginx, Gunicorn ou quoi que ce soit d'autre. django-extensionsfournit un runserver_plusqui utilise le framework Werkzeug, mais qui est aussi proche d'un serveur que n'importe quel autre runserver.

— Mike DeSimone

Il est généralement préférable d'exécuter Python dans un processus distinct de votre serveur Web principal. De cette façon, le serveur Web peut avoir beaucoup de petits threads qui servent du contenu statique très rapidement, tandis que vos processus Python séparés seront gros et lourds et chacun exécutera son propre interpréteur Python. Si simple WSGIest mauvais, car cela gonfle chacun de vos threads nginx avec un gros interpréteur Python. Utiliser flupou gunicornou uWSGIderrière nginxest bien meilleur, car cela libère nginx pour simplement servir du contenu et vous permet de choisir le nombre de petits threads nginx légers à exécuter, indépendamment de votre choix du nombre de threads Python lourds que vous utilisez pour servir du contenu dynamique. Les gens semblent très satisfaits pour gunicornle moment, mais l'une de ces trois options devrait fonctionner correctement.

À l'avenir, cela vous permet également de déplacer le Python vers un autre serveur lorsque la charge commence à devenir sérieuse.

— Brandon Rhodes
source

Je suis un peu confus par votre réponse. Je ne vois pas qu'il a mentionné l'exécution d'une quelconque implémentation WSGI à l'intérieur de nginx. Il a fait référence au site principal wsgi.org. Sa comparaison originale entre WSGI et uWSGI est donc un peu ridicule en premier lieu car uWSGI est une implémentation de la spécification WSGI. Vous avez vous-même utilisé le terme WSGI générique d'une manière déroutante en disant que "cela gonfle chacun de vos threads nginx avec un gros interpréteur Python". La spécification WSGI elle-même ne peut pas faire cela, seules les implémentations le peuvent.

— Graham Dumpleton

Cela pourrait avoir du sens si nous comparions nginx + mod_wsgi (le module enfichable) et nginx + uWSGI (le conteneur du serveur d'applications).

— clime

Donc, quand il s'agit d'utiliser Nginx pour exécuter des applications Web Python, puisque le mod_wsgi de Manlio Perillo est un logiciel mortel et n'est pas recommandé, les bonnes solutions sont soit WSGI avec gunicorn ou uWSGI, ou FastCGI avec Flup?

— Gulbahar

Je crois que ce droit ici http://flask.pocoo.org/docs/deploying/uwsgi/ est une bonne réponse pour dissiper la confusion. La question n'est pas idiote, arrive à quiconque voit les deux termes et n'a aucune information préalable sur la façon dont les choses fonctionnent en dehors du monde mod_PHP (par exemple, rien contre php ou les gens)

Le site fait bien d'expliquer en termes pratiques ce qui est nécessaire et quelle est la différence ainsi qu'un bon exemple de déploiement pour nginx.

Pour plus de commodité, l'explication du wiki Flask est citée ici:

uWSGI est une option de déploiement sur des serveurs tels que nginx, lighttpd et cherokee; voir FastCGI et conteneurs WSGI autonomes pour d'autres options. Pour utiliser votre application WSGI avec le protocole uWSGI, vous aurez d'abord besoin d'un serveur uWSGI. uWSGI est à la fois un protocole et un serveur d'applications; le serveur d'applications peut servir les protocoles uWSGI, FastCGI et HTTP.

Le serveur uWSGI le plus populaire est uwsgi, que nous utiliserons pour ce guide. Assurez-vous de l'avoir installé pour suivre.

— Abhishek Dujari
source