Frage Warum brauche ich nginx wenn ich uWSGI habe?


Es gibt viele Anleitungen zur Konfiguration von nginx für die Zusammenarbeit mit uWGSI, wenn ich Django-Anwendungen bereitstellen möchte.

Aber warum brauche ich nginx in diesem Kit? uWSGI selbst kann WSGI-Python-Anwendungen bedienen, es kann statische Dateien bereitstellen, es kann auch SSL ausführen. Was kann nginx tun, was uWSGI nicht kann?


52
2018-04-23 14:44


Ursprung


Ich kann sehen, dass diese Frage als auf Meinung basiert geschlossen ist. Ich stimme überhaupt nicht zu. Frage "Was kann Nginx tun, was uWSGI nicht kann?" basiert auf Tatsachen. - user983447
Ich spreche normalerweise nicht für Wiedereröffnungen, aber in diesem Fall stimme ich zu. Die bestehende, aufgewertete und akzeptierte Antwort ist eine gute, die zeigt, dass die Frage, wie geschrieben, vernünftige und relevante Antworten zulässt; Ich denke, das macht es wahrscheinlich eine gute Frage. - MadHatter


Antworten:


Du nicht.

Das ist sowieso die einfache Antwort - du nicht brauchen es. uWSGI ist selbst ein fähiger Server.

Andere Server wie nginx sind jedoch schon länger verfügbar und sind (wahrscheinlich sowieso) sicherer und haben zusätzliche Funktionen, die nicht von uWSGI unterstützt werden - zum Beispiel die verbesserte Handhabung von statischen Ressourcen (über eine beliebige Kombination von Expires oder E-Tag) Header, Gzip-Komprimierung, vorkomprimiertes Gzip usw.), die die Server- und Netzwerklast erheblich reduzieren können; Darüber hinaus kann ein Server wie nginx vor Ihrer Django-Anwendung das Caching Ihrer dynamischen Inhalte implementieren, wodurch die Serverlast weiter reduziert und sogar die Verwendung eines CDN erleichtert wird (die normalerweise mit dynamischen Inhalten nicht gut zurechtkommen) ). Sie könnten sogar noch weiter gehen und Nginx auf einem völlig separaten Server haben, Reverse-Proxy-Anforderungen für dynamischen Inhalt an einen lastausgeglichenen Cluster von Anwendungsservern, während der statische Inhalt selbst gehandhabt wird.

Zum Beispiel ist mein Blog (während es WordPress ist, hat es Nginx vor ihm) ist abgestimmt, Beiträge für 24 Stunden zu cachen, und Indexseiten für 5 Minuten zu cachen; Während ich nicht genug Verkehr sehe, um die meiste Zeit wirklich wichtig zu sein, hilft es meinem winzigen VPS, den gelegentlichen Anstieg zu verhindern, der es sonst niederschlagen könnte - wie die große Welle des Verkehrs, als einer meiner Artikel ausgewählt wurde von einem Twitterer mit vielen Tausenden von Followern, von denen viele es zu ihren Tausenden von Followern re-twitterten.

Wenn ich einen "nackten" uWSGI-Server laufen hätte (und angenommen, dass es eine Django-Site statt WordPress gewesen wäre), hätte es wahrscheinlich alles gut ausgehalten - oder es wäre abgestürzt und verbrannt, was mich an verpassten Besuchern gekostet hätte . Es kann wirklich helfen, nginx vor sich zu haben, um mit dieser Last umzugehen.

Wenn Sie nur eine kleine Website betreiben, auf der nicht viel Traffic zu sehen ist, brauchen Sie nginx oder etwas anderes nicht - verwenden Sie einfach uWSGI, wenn Sie das möchten. Auf der anderen Seite, wenn Sie viel Verkehr sehen ... nun, Sie immer noch vielleicht wollen Sie uWSGI, aber Sie sollten zumindest etwas vor, um mit der Last zu helfen. Eigentlich sollten Sie verschiedene Konfigurationen mit Ihrer fertigen Website testen, um herauszufinden, was unter Ihrer erwarteten Auslastung für Sie am besten funktioniert, und alles verwenden, was Ihnen letztendlich zusteht.


47
2018-04-23 15:25



Die eine Sache, die mir in den Sinn kommt, ist neben dem, was @Kromey in ihrer Antwort behandelt, dass das native Protokoll für uWSGI nicht http, sondern das uwsgi-Protokoll ist. Das uwsgi-Protokoll ist einfacher und effizienter zu handhaben als http, und das Kleben eines voll funktionsfähigen Web-Servers (nginx oder whatnot) vor Ihrer uWSGI-Anwendung führt nicht zu einer großen Anzahl von Verarbeitungsvorgängen und kann je nach Ihrem Nutzen erhebliche Vorteile bringen braucht. - Håkan Lindqvist
@ HåkanLindqvist ist absolut richtig; nur um zu verdeutlichen, uWSGI ist zwar durchaus in der Lage, HTTP zu "sprechen", kann also für sich alleine gut stehen, aber es ist durchaus erwähnenswert, dass ein Webserver davor das uwsgi-Protokoll, nicht HTTP, verwendet Sprechen Sie mit uWSGI, und daher, ja, sehr wenig Doppelarbeit bei der Verarbeitung beteiligt. - Kromey
Dies ist eine gute Antwort, aber es könnte mit einem Link zu uWSGI eigenen Dokumentation zu dem Thema verbessert werden, die mit mehr Details, was Sie erklärt können mit uWSGI machen: uwsgi-docs.readthedocs.io/de/latest/... - Tobias McNulty


IMO, wenn Sie Ihre Web site in Internet anstelle von Labor setzen, sehen Sie möglicherweise den Unterschied.

Stellen Sie sich einen Benutzer aus einem anderen Land mit niedriger Netzwerkgeschwindigkeit vor, der den Webbrowser für den Zugriff auf Ihre Website öffnet. uWSGI wird diese HTTP-Verbindung in einem Thread behandeln. Dieser Thread kann ziemlich lange dauern, um auf eine vollständige HTTP-Anforderung aufgrund der niedrigen Netzwerkgeschwindigkeit zu warten. Wenn Ihre Thread-Pool-Größe 100 ist, stellen Sie sich 100 Benutzer langsam vor, was wird passieren? Kein leerer Thread, um andere HTTP-Anfragen zu bearbeiten.

Aber für Nginx ist das ganz anders. Nginx ist in 'Reactor Pattern' designed. Sie können Google 'Reactor Pattern' googeln, um zu sehen, wie es funktioniert. Kurz gesagt, eine langsame Verbindung hat keine Auswirkungen auf andere HTTP-Anfragen.


1
2018-05-26 09:45



Ich bezweifle, dass die Verwendung von Nginx das ändern wird. Wenn eine Django-Anwendung unter Verwendung von WSGI auf Apache gehostet wird, wird die Ansichtsfunktion aufgerufen, bevor POST-Daten von einem Socket gelesen werden. Wenn der Client langsam ist, belegt er einen Thread von der Anforderung, bis die POST-Daten empfangen wurden. Warum sollte das Ersetzen von Apache durch Nginx das ändern? - kasperd
Wie ich weiß, wird Nginx die HTTP-Anfrage standardmäßig nicht an den Backend-Anwendungsserver weiterleiten, bis eine vollständige HTTP-Anfrage eingegangen ist. Also für Anwendungsserver wie Django, was sie bekommen, ist immer eine schnelle HTTP-Verbindung und Anfrage, keine Zeit verschwendet für das Warten auf eine vollständige HTTP-Anfrage, nach der Bearbeitung der Quest bald, könnte der laufende Thread für die nächste HTTP-Anfrage bald untätig sein. - jcyrss
Es wird Request Buffering genannt, welches standardmäßig in Nginx aktiviert ist (in älteren Versionen von Nginx war das nicht möglich): nginx.org/de/docs/http/... - Tobias McNulty