Cet article est une traduction de l'article de Kevin Goldberg «An Introduction to Python WSGI Servers: Part 1» blog.appdynamics.com/engineering/an-introduction-to-python-wsgi-servers-part-1 avec de petits ajouts du traducteur
Une brève histoire des serveurs WSGI Python
Les serveurs
WSGI sont apparus car les serveurs Web à cette époque n'étaient pas en mesure d'interagir avec les applications écrites en Python.
WSGI (
prononcé «whiz-gee» avec un «g» solide ) a été développé par Philip J. Ebi (avec Ian Biking et d'autres) au début des années 2000. Le module Apache, connu sous le nom de
mod_python , développé par Grigory Trubetskoy à la fin des années 90, traitait à l'époque la plupart des applications Python. Cependant,
mod_python n'était pas une spécification officielle. Il a été simplement créé pour que les développeurs puissent exécuter du code Python sur le serveur. Malheureusement, cette approche n'était pas sûre et les développeurs ont commencé à chercher une nouvelle solution.
WSGI (Web-Server Gateway Interface) est un descendant de
CGI (Common Gateway Interface). Lorsque le Web a commencé à évoluer,
CGI s'est développé en raison de la prise en charge d'un grand nombre de langues et du manque d'autres solutions. Cependant, cette solution était lente et limitée.
WSGI a été développé comme interface pour acheminer les demandes des serveurs Web (Apache, Nginx, etc.) vers les applications Web.
Serveur et application Web
Dans le cas le plus simple,
WSGI se compose de deux entités principales:
- Serveur Web ( Nginx, Apache , etc.);
- Une application web écrite en Python.
Principe de fonctionnement:
Le serveur Web exécute le code et envoie les informations et la fonction de rappel associées à la demande http à l'application Web. Ensuite, la demande côté application est traitée et une réponse est envoyée au serveur Web.
Périodiquement, entre le serveur Web et l'application Web, une ou plusieurs couches intermédiaires existent. De telles couches permettent, par exemple, d'équilibrer entre plusieurs applications Web et de prétraiter (prétraitement) du contenu livré.
Voici des exemples de frameworks qui prennent en charge WSGI:
Pourquoi WSGI?
Vous pourriez demander,
"OK, mais pourquoi WSGI?" . Il y a plusieurs raisons à cela:
- Les serveurs WSGI ont été conçus pour gérer de nombreuses demandes à la fois. Et les cadres ne sont pas conçus pour gérer des milliers de demandes et ne décident pas de la meilleure façon de les acheminer (demandes) à partir du serveur Web.
- WSGI accélère le développement d'applications Web écrites en Python. Si vous utilisez un framework (Django ou autre) dans le développement de votre application Web, vous n'avez pas à vous soucier de la façon dont votre infrastructure particulière utilise la norme WSGI .
- WSGI vous donne la flexibilité de modifier les composants de la pile Web sans changer l'application qui fonctionne avec WSGI .
Les serveurs
WSGI sont disponibles en différentes variantes. Certains visent une solution fullstack, tandis que d'autres sont bien adaptés à des cadres spécifiques. Par exemple,
Gunicorn travaille avec
Django dès la sortie de la boîte. Voici un aperçu des six serveurs WSGI sur le marché aujourd'hui:
Bjoern ,
uWSGI ,
mod_wsgi ,
Meinheld ,
CherryPy et
Gunicorn .
Bjoern
Bjoern est un serveur WSGI asynchrone écrit en C. Écrit à partir de
zéro pour être petit et rapide, il a été développé en utilisant
http_parser de Ryan Dahl (créateur de Node.js) et la
boucle d' événement
Libev de Mark Lehmann.
Avec une taille de téléchargement de seulement 18 Ko, il se compose de moins de 800 lignes de code. Il prend moins de 1 Mo de RAM et n'utilise pas de
coroutines ou de threads.
Bjoern est entièrement compatible avec
WSGI et est considéré comme l'un des serveurs
WSGI les plus performants.
Bjoern prend en charge les connexions persistantes et peut se lier aux sockets Unix ou aux adresses TCP.
Bjoern est considéré comme plus rapide que Gunicorn et moins gonflé que
uWSGI et
Meinheld . L'un des inconvénients de ce serveur est le manque de documentation normale avec des exemples clairs.
uWSGI
uWSGI a été développé par
Unbit (Italie) dans le but de devenir une solution fullstack capable de créer des services d'hébergement. Il porte le nom de la norme
WSGI et a été créé en tant que plug-in pour l'un des projets de l'entreprise.
Un projet vaste et en constante évolution,
uWSGI vous permet de faire bien plus que des applications d'hébergement Web. Beaucoup trouvent
uWSGI un outil puissant, tandis que d'autres le trouvent quelque peu gonflé. À partir de la version 2.0, uWSGI prend également en charge le lancement d'applications Web dans les langues Lua, Perl, Ruby et autres.
mod_wsgi
mod_wsgi , un module serveur Apache HTTP développé par Graham Dumpleton (anciennement l'un des développeurs
mod_python ), fournit l'interface
WSGI pour les applications Web. Compatible avec les versions linguistiques Python2 et Python3. Créé comme une alternative à d'autres solutions pour l'intégration d'applications Web telles que
CGI ,
FastCGI et
mod_python . Il peut être installé en tant que module Apache ou via
mod_wsgi express . La deuxième méthode simplifie l'installation pour les développeurs Python qui ne sont pas si familiers avec Apache. Autres avantages:
• Vous n'avez pas besoin des privilèges root avec une installation complète.
• Un environnement local est créé, ce qui réduit le risque d'impact négatif sur les paramètres existants.
Le développement de
mod_wsgi en tant que projet peut sembler lent en raison du fait que le module est développé par un développeur. Un autre inconvénient est que la documentation est actuellement mal organisée et peut être obsolète.
Actuellement, l'accent est mis sur la simplification de l'implémentation d'Apache à l'aide de
mod_wsgi dans des environnements utilisant
Docker .
Meinheld
Créé par Yutaka Matsubara,
Meinheld est un serveur compatible
WSGI qui exploite la puissance de
picoev et de
greenlet pour effectuer des E /
S asynchrones. Il peut être utilisé avec un serveur HTTP autonome ou via
Gunicorn .
Meinheld a une dépendance sur un composant tiers appelé greenlet.
Le référentiel de code source est situé sur
GitHub .
Meinheld prend en charge les sockets Web et inclut plusieurs
monkeypatches sur d'autres modules pour des fonctionnalités améliorées.
Cherrypy
CherryPy - mieux connu sous le nom de framework Python minimaliste pour l'écriture d'applications Web,
CherryPy est également livré avec un serveur Web WSGI regroupé et un support pour le protocole HTTP / 1.1. L'équipe de développement
CherryPy décrit son serveur Web comme un serveur HTTP à pool de threads, prêt pour la production et à grande vitesse. Il a:
• Configuration rapide et facile;
• évolutivité;
• Une solution petite et facile à utiliser pour vos applications Python;
• Prise en charge SSL.
CherryPy se distingue des serveurs
WSGI les plus connus en raison de sa facilité d'utilisation et de la commodité pour les développeurs. Vous pouvez écrire une petite application Web en quelques minutes en l'exécutant dans plusieurs processus et en créant un seul fichier appelé server.py. En combinant
CherryPy avec Nginx en tant que serveur proxy, vous obtenez un moyen fiable de servir vos applications Web.
CherryPy a été créé par Remy Delon. Il voulait créer une structure qui serait aussi proche que possible des
grands principes de développement en Python .
Gunicorn
Gunicorn est un
serveur WSGI conçu pour être utilisé sur les systèmes UNIX. Le nom est une version abrégée et combinée des mots «Licorne verte». Il y a une licorne verte sur le site du projet lui-même.
Gunicorn a été porté à partir du projet Unicorn de Ruby. Il est relativement rapide, gourmand en ressources, facile à lancer et fonctionne avec une large gamme de frameworks Web.
L'équipe de développement recommande d'utiliser
Gunicorn en conjonction avec Nginx, où Nginx est utilisé comme serveur proxy.
Conclusion
Dans cet article, les six serveurs WSGI les plus populaires du moment ont été
analysés :
Bjoern ,
uWSGI ,
mod_wsgi ,
Meinheld ,
CherryPy et
Gunicorn . Le serveur à utiliser dépend des conditions et des exigences de votre application. La prochaine partie analysera les performances de ces six serveurs WSGI.