Dieser Artikel ist eine Übersetzung von Kevin Goldbergs Artikel "Eine Einführung in Python-WSGI-Server: Teil 1" blog.appdynamics.com/engineering/an-introduction-to-python-wsgi-servers-part-1 mit kleinen Ergänzungen des Übersetzers
Eine kurze Geschichte der WSGI-Python-Server
WSGI- Server wurden
angezeigt, weil Webserver zu diesem Zeitpunkt nicht mit in Python geschriebenen Anwendungen interagieren konnten.
WSGI (
ausgesprochen "whiz-gee" mit einem festen "g" ) wurde von Philip J. Ebi (zusammen mit Ian Biking und anderen) in den frühen 2000er Jahren entwickelt. Das Apache-Modul, bekannt als
mod_python , das Ende der 90er Jahre von Grigory Trubetskoy entwickelt wurde, verarbeitete zu dieser Zeit die meisten Python-Anwendungen.
Mod_python war jedoch keine offizielle Spezifikation. Es wurde einfach erstellt, damit Entwickler Python-Code auf dem Server ausführen können. Leider war dieser Ansatz unsicher und die Entwickler suchten nach einer neuen Lösung.
WSGI (Web-Server Gateway Interface) ist ein Nachkomme von
CGI (Common Gateway Interface). Als sich das Web weiterentwickelte, wuchs
CGI aufgrund der Unterstützung einer großen Anzahl von Sprachen und des Mangels an anderen Lösungen. Diese Lösung war jedoch langsam und begrenzt.
WSGI wurde als Schnittstelle zum Weiterleiten von Anforderungen von Webservern (Apache, Nginx usw.) an Webanwendungen entwickelt.
Server und Webanwendung
Im einfachsten Fall besteht
WSGI aus zwei Hauptentitäten:
- Webserver ( Nginx, Apache usw.);
- Eine in Python geschriebene Webanwendung.
Arbeitsprinzip:
Der Webserver führt den Code aus und sendet die mit der http-Anforderung verknüpften Informationen und die Rückruffunktion an die Webanwendung. Anschließend wird die Anforderung auf der Anwendungsseite verarbeitet und eine Antwort an den Webserver gesendet.

In regelmäßigen Abständen existieren zwischen dem Webserver und der Webanwendung eine oder mehrere Zwischenschichten. Solche Schichten ermöglichen beispielsweise das Ausgleichen zwischen mehreren Webanwendungen und die Vorverarbeitung (Vorverarbeitung) des gelieferten Inhalts.
Hier sind Beispiele für Frameworks, die WSGI unterstützen:
Warum WSGI?
Sie könnten fragen:
"OK, aber warum WSGI?" . Dafür gibt es mehrere Gründe:
- WSGI- Server wurden entwickelt, um viele Anforderungen gleichzeitig zu verarbeiten. Und die Frameworks sind nicht dafür ausgelegt, Tausende von Anfragen zu verarbeiten, und geben keine Entscheidung darüber, wie sie (Anfragen) am besten vom Webserver weitergeleitet werden sollen.
- WSGI beschleunigt die Entwicklung von in Python geschriebenen Webanwendungen. Wenn Sie in Ihrer Webanwendungsentwicklung ein Framework (Django oder etwas anderes) verwenden, müssen Sie sich keine Gedanken darüber machen, wie Ihre spezielle Infrastruktur den WSGI- Standard verwendet.
- WSGI bietet Ihnen die Flexibilität, Webstack-Komponenten zu ändern, ohne die mit WSGI funktionierende Anwendung zu ändern.
WSGI- Server sind in verschiedenen Varianten erhältlich. Einige zielen auf eine Fullstack-Lösung ab, während andere für bestimmte Frameworks gut geeignet sind. Zum Beispiel arbeitet
Gunicorn sofort mit
Django zusammen . Hier sehen Sie sich die sechs derzeit auf dem Markt befindlichen WSGI-Server genauer an:
Bjoern ,
uWSGI ,
mod_wsgi ,
Meinheld ,
CherryPy und
Gunicorn .
Björn
Bjoern ist ein asynchroner WSGI-Server, der in C geschrieben wurde. Er wurde von Grund auf klein und schnell geschrieben und mit
http_parser von Ryan Dahl (
Erfinder von Node.js) und der
Libev- Ereignisschleife von Mark Lehmann entwickelt.
Mit einer Downloadgröße von nur 18 KB besteht es aus weniger als 800 Codezeilen. Es benötigt weniger als 1 MB RAM und verwendet keine
Coroutinen oder Threads.
Bjoern ist vollständig kompatibel mit
WSGI und gilt als einer der leistungsstärksten
WSGI- Server.
Bjoern unterstützt dauerhafte Verbindungen und kann an Unix-Sockets oder TCP-Adressen binden.
Björn gilt als schneller als Gunicorn und weniger aufgebläht als
uWSGI und
Meinheld . Einer der Nachteile dieses Servers ist das Fehlen einer normalen Dokumentation mit klaren Beispielen.
uWSGI
uWSGI wurde von
Unbit (Italien) mit dem Ziel entwickelt, eine Fullstack-Lösung zu werden, mit der Hosting-Services erstellt werden können. Es ist nach dem
WSGI- Standard benannt und wurde als Plug-In für eines der Projekte des Unternehmens erstellt.
Mit
uWSGI, einem umfassenden und sich ständig weiterentwickelnden Projekt, können Sie viel mehr als nur Webhosting-Anwendungen
ausführen . Viele finden
uWSGI ein mächtiges Werkzeug, andere finden es etwas aufgebläht. Ab Version 2.0 unterstützt uWSGI auch das Starten von Webanwendungen in den Sprachen Lua, Perl, Ruby und anderen.
mod_wsgi
mod_wsgi , ein Apache HTTP-
Servermodul , das von Graham Dumpleton (ehemals einer der
mod_python- Entwickler) entwickelt wurde, bietet die
WSGI- Schnittstelle für Webanwendungen. Kompatibel mit Python2- und Python3-Sprachversionen. Entwickelt als Alternative zu anderen Lösungen zur Integration von Webanwendungen wie
CGI ,
FastCGI und
mod_python . Es kann als Apache-Modul oder über
mod_wsgi Express installiert werden. Die zweite Methode vereinfacht die Installation für Python-Entwickler, die mit Apache nicht so vertraut sind. Weitere Vorteile:
• Bei einer vollständigen Installation benötigen Sie keine Root-Rechte.
• Es wird eine lokale Umgebung erstellt, die das Risiko negativer Auswirkungen auf vorhandene Einstellungen verringert.
Die Entwicklung von
mod_wsgi als Projekt kann langsam erscheinen, da das Modul von einem Entwickler entwickelt wird. Ein weiterer Nachteil ist, dass die Dokumentation derzeit schlecht organisiert und möglicherweise veraltet ist.
Derzeit liegt der Schwerpunkt auf der Vereinfachung der Implementierung von Apache mithilfe von
mod_wsgi in Umgebungen mit
Docker .
Meinheld
Meinheld wurde von Yutaka Matsubara entwickelt
und ist ein
WSGI- kompatibler Server, der die Leistung von
Picoev und
Greenlet nutzt , um asynchrone E /
A durchzuführen. Es kann mit einem eigenständigen HTTP-Server oder über
Gunicorn verwendet werden .
Meinheld ist von einer Drittanbieter-Komponente namens greenlet abhängig.
Das Quellcode-Repository befindet sich auf
GitHub .
Meinheld unterstützt Web-Sockets und enthält mehrere
Monkeypatches gegenüber anderen Modulen, um die Funktionalität zu verbessern.
Cherrypy
CherryPy - besser bekannt als minimalistisches Python-Framework zum Schreiben von Webanwendungen.
CherryPy verfügt außerdem über einen WSGI-Webserver mit Thread-
Pool und Unterstützung für das HTTP / 1.1-Protokoll. Das
CherryPy- Entwicklungsteam beschreibt seinen Webserver als produktionsbereiten Hochgeschwindigkeits-HTTP-Server mit Thread-Pool. Er besitzt:
• Schnelle und einfache Einrichtung;
• Skalierbarkeit;
• Eine kleine und benutzerfreundliche Lösung für Ihre Python-Anwendungen.
• SSL-Unterstützung.
CherryPy unterscheidet sich von den bekannteren
WSGI- Servern durch seine Benutzerfreundlichkeit und Entwicklerfreundlichkeit. Sie können eine kleine Webanwendung in wenigen Minuten schreiben, indem Sie sie in mehreren Prozessen ausführen und nur eine Datei mit dem Namen server.py erstellen. Durch die Kombination von
CherryPy mit Nginx als Proxyserver erhalten Sie eine zuverlässige Möglichkeit, Ihre Webanwendungen
bereitzustellen .
CherryPy wurde von Remy Delon erstellt. Er wollte eine Struktur schaffen, die
den Hauptprinzipien der Entwicklung in Python so nahe wie möglich kommt.
Gunicorn
Gunicorn ist ein
WSGI- Server, der für die Verwendung auf UNIX-Systemen entwickelt wurde. Der Name ist eine gekürzte und kombinierte Version der Wörter "Green Unicorn". Auf dem Projektgelände befindet sich ein grünes Einhorn.
Gunicorn wurde aus dem Unicorn-Projekt von Ruby portiert. Es ist relativ schnell, ressourcenintensiv, einfach zu starten und funktioniert mit einer Vielzahl von Webframeworks.
Das Entwicklungsteam empfiehlt die Verwendung von
Gunicorn in Verbindung mit Nginx, wo Nginx als Proxyserver verwendet wird.
Fazit
In diesem Artikel wurden die derzeit sechs beliebtesten WSGI-Server
analysiert :
Bjoern ,
uWSGI ,
mod_wsgi ,
Meinheld ,
CherryPy und
Gunicorn . Welcher Server für Sie verwendet werden soll, hängt von den Bedingungen und Anforderungen für Ihre Anwendung ab. Im nächsten Teil wird die Leistung dieser sechs WSGI-Server analysiert.