Ich beabsichtige, mit einem einzigen VPS mehrere verkehrsarme CherryPy-Apps als Unterverzeichnisse bereitzustellen. zB: example.com/app1, example.com/app2usw.

Nach der Untersuchung der WSGI-Bereitstellung scheint die bevorzugte Methode für die Bereitstellung von Apps darin zu bestehen, einen WSGI-Server (Gunicorn, uWSGI usw.) und NGinx in einem Reverse-Proxy-Setup zu verwenden. Es scheint übertrieben, zwei Webserver gleichzeitig zu verwenden - zumal meine CherryPy-App selbst ein Webserver ist -, aber ich möchte die Idee nicht verwerfen, da sie überall erscheint . Ich bin sicherlich kein Experte, deshalb würde ich gerne darüber diskutieren.

Ich sehe drei Möglichkeiten:

• Stellen Sie CherryPy selbst bereit.
• Bereitstellung unter Gunicorn oder einem anderen WSGI-Server.
• Bereitstellung unter einem WSGI-Server und Reverse-Proxy für NGinx, was anscheinend die Lösung für alle ist.

Meine Fragen:

• Was ist der Hauptgrund, warum ich dieses Muster überall sehe? Ist NGinx einfach so gut?
• Ist der native CherryPy-Server für Apps mit geringem Datenverkehr gut genug oder sollte ich es nicht einmal versuchen?

Jeder Rat wird geschätzt, danke.

Der Grund, warum jeder Nginx (oder einen anderen Server wie Apache) vor seine App-Server stellt, ist, dass jeder statische Inhalte wie Bilder, CSS und JavaScript sowie seltsame Anforderungen hat, die für seine Anwendung einzigartig sind.

Ihr App-Server (CherryPy, Gunicorn, was auch immer) ist so optimiert, dass Ihre App ausgeführt und ihre Ausgabe bereitgestellt wird. Der App-Server kann zwar auch statische Inhalte bereitstellen, ist jedoch für diese Aufgabe fast nie gut optimiert, da er dem Hauptzweck des App-Servers untergeordnet ist. (Einige App-Server helfen auch, indem sie CSS und JS minimieren und komprimieren, sodass der vordere Webserver diese Ressourcen noch schneller bereitstellen kann.)

Darüber hinaus kann der eigentliche Webserver viel mehr als nur die Bereitstellung von Hochleistungsinhalten. Dinge wie Caching, Manipulation von Headern, Umschreiben von URLs, Geolocation und viele andere Funktionen, die den App-Server nur zu einem guten Zweck aufblähen würden.

Normalerweise führen Sie den App-Server nur dann alleine aus, wenn Sie die Anwendung entwickeln, wenn Sie der einzige Benutzer sind und die Leistung kein Problem darstellt. Selbst wenn Ihre Website wenig Verkehr hat, möchten Sie, dass sie schneller ist, oder? Websites mit geringem Verkehr, die langsam sind, wachsen im Allgemeinen nicht zu Websites mit hohem Datenverkehr ...

Warum setzen die Leute Nginx in den Vordergrund?

1. Nginx ist ein asynchroner Web-Server. Dies bedeutet, dass kein Thread oder Prozess pro Verbindung zugewiesen wird. Stattdessen wird die bevorzugte Socket-Polling-Bibliothek des Betriebssystems verwendet und somit hunderttausende von Verbindungen verarbeitet. Warum sollten Sie sich als Anwendungsentwickler darum kümmern? Weil Nginx Verbindungen puffert und die Anforderung nur dann an Ihre CherryPy-Upstream-Instanz weiterleitet, wenn die Anforderung vollständig gelesen wurde. Gleiches gilt für Antworten. Auf diese Weise wird Ihre CherryPy-Anwendung, die in vielerlei Hinsicht ein Thread-Server hinter Nginx ist, asynchron. Insbesondere winken Sie einem langsamen Client-Problem und langsamen Loris-DOS-Angriffen zu.
2. Bei Nginx ist die Verbindungsrate sofort einsatzbereit. Angenommen, ich möchte nicht mehr als 8 gleichzeitige Verbindungen von derselben IP.
3. CherryPy hat ein SSL-Problem . Nginx nicht.
4. Python kann Bytes fast so gut hin und her senden wie C. Pythons zlibist nur ein Wrapper um die C-Bibliothek. Da Nginx die Verbindung jedoch effektiv verwaltet, ist es eine gute Idee, Ihre CherryPy-Worker-Threads von der Bereitstellung statischer Inhalte in der Produktion zu entlasten und sich nur dynamischen Inhalten zu widmen.
5. Multiplexen mehrerer CherryPy-Instanzen auf demselben Port, derselben Domäne, demselben Pfad usw. Im Allgemeinen zusätzliche Flexibilität einer anderen Konfigurationsebene.

Ist es sicher, CherryPy alleine zu verwenden?

Laut einem der ursprünglichen Autoren ja . Die meisten webrelevanten Dinge, die Sie mit CherryPy alleine tun können.

CherryPy hat eine Anwendungsvorstellung und Sie können mehrere Anwendungen mit einer CherryPy-Instanz bereitstellen. CherryPy kann auch andere WSGI-Anwendungen bedienen .

Bereitstellen von CherryPy

In einer herkömmlichen Bereitstellung im * nix-Stil schreiben Sie ein Init-Skript, dämonisieren Ihre Verarbeitung, löschen seine Berechtigungen, schreiben seine PID usw. Wenn Sie über mehrere CherryPy-Instanzen verfügen, ist dies keine große Sache. Wenn Sie Dutzende haben, wird es mühsam und es ist sinnvoll, das Prozessmanagement an Gunicorn oder uWGSI zu übergeben und Ihre CherryPy-Instanzen von HTTP auf WSGI umzustellen.

Ich habe ein Tutorial / Projekt-Skelett geschrieben, cherrypy-webapp-skeleton . Ziel war es, die Lücken für die (traditionelle) Bereitstellung einer realen CherryPy-Anwendung auf Debian für einen Webentwickler zu schließen.

Einpacken

1. Wenig Verkehr, keine besonderen Anforderungen → CherryPy * 1 ⇐ HTTP ⇒ Client.
2. Starker Verkehr, besondere Anforderungen → CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.
3. Dutzende von separaten CherryPy-Instanzen auf demselben Server, die darauf bedacht sind, die Lösung aller zu übertreffen → CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.