Quelqu'un pourrait-il expliquer les avantages et les inconvénients de l'utilisation de WSGI VS uWSGI avec Nginx.
Je suis actuellement en train de construire un serveur de production pour le site web Django que j'ai préparé mais je n'arrive pas à décider si je dois utiliser WSGI ou uWSGI. Pourriez-vous m'expliquer en détail ce qui différencie chaque configuration ? Quelle configuration est la plus évolutive ?
Merci d'avance
Ok, les gars, cette confusion est due au manque de détails de plusieurs sources, et à la dénomination de ces protocoles, et à ce qu'est réellement WSGI.
Résumé :
Erreur de frappe : "1. uwsgi est un protocole et non un serveur." --> "1. WSGI est un protocole et non un serveur."
En fait, ce que j'ai écrit pour 1 est correct, mais il 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 pas confondre le protocole uwsgi avec le serveur uWSGI (qui parle le protocole uwsgi)".
Ah, ok. J'avais pensé que vous essayiez d'établir une contradiction entre l'affirmation 1. "wsgi est un protocole " et 2. "uwsgi est un serveur qui implémente le protocole".
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 le contenu statique très rapidement, tandis que vos processus Python séparés seront gros et lourds et exécuteront chacun leur propre interpréteur Python. Donc, simple WSGI n'est pas une bonne chose, car elle gonfle chacun de vos threads nginx avec un gros interpréteur Python. Utilisation de flup ou gunicorn ou uWSGI derrière nginx est bien meilleure, car elle libère nginx pour qu'il serve simplement le contenu, et vous permet de choisir le nombre de petits threads légers de nginx à exécuter, indépendamment de votre choix du nombre de threads lourds de Python que vous utilisez pour servir le contenu dynamique. Les gens semblent très heureux avec gunicorn pour le moment, mais n'importe laquelle de ces trois options devrait fonctionner correctement.
À l'avenir, cela vous permettra également de déplacer le Python vers un autre serveur lorsque la charge commencera à être importante.
Je suis un peu confus par votre réponse. Je ne vois pas qu'il ait mentionné l'exécution d'une sorte d'implémentation WSGI à l'intérieur de nginx. Il a fait référence au site principal wsgi.org. Sa comparaison initiale entre WSGI et uWSGI est donc un peu stupide, car uWSGI est une implémentation de la spécification WSGI. Vous avez vous-même utilisé le terme générique WSGI d'une manière confuse 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.
Cela pourrait avoir un sens si nous comparions nginx + mod_wsgi (le module enfichable) et nginx + uWSGI (le conteneur du serveur d'applications).
Je crois que c'est ici même http://flask.pocoo.org/docs/deploying/uwsgi/ est une bonne réponse pour dissiper la confusion. La question n'est pas idiote, elle se pose à toute personne qui voit les deux termes et qui 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 explique bien 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 comme nginx, lighttpd et cherokee ; voir FastCGI et Standalone WSGI Containers 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'application ; le serveur d'application peut servir les protocoles uWSGI, FastCGI et HTTP.
Le serveur uWSGI le plus populaire est uwsgi, que nous utiliserons dans ce guide. Assurez-vous de l'avoir installé pour pouvoir suivre le guide.
Cet article de blog est une comparaison très détaillée de nombreux serveurs WSGI en Python, avec un résumé et quelques recommandations à la fin.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
1 votes
Cet article de blog est une comparaison très détaillée de nombreux serveurs WSGI en Python, avec un résumé et quelques recommandations à la fin.
0 votes
Il utilise également des configurations pour certains serveurs qui sont vraiment douteuses et les fait apparaître plus mauvais qu'ils ne peuvent l'être. Il faut faire attention à ce que l'on lit dans cette comparaison.
27 votes
WSGI est une spécification. uWSGI fournit une implémentation de la spécification WSGI. Vous ne pouvez pas les comparer. Vous pouvez seulement comparer différentes implémentations.