Antworten:
Ich werde mich auf das langsame Client-Verhalten konzentrieren und darauf, wie Ihre Konfiguration damit umgeht, aber seien Sie nicht versucht zu glauben, dass dies der einzige Vorteil ist. Die gleiche Methode, die langsamen Clients zugute kommt, bietet auch Vorteile für schnelle Clients, für die SSL-Verarbeitung, für den Umgang mit Datenverkehrsschwankungen und für andere Aspekte der Bereitstellung von HTTP im Internet.
Gunicorn ist eine Vorgabelsoftware. Für Kommunikationen mit geringer Latenz, wie z. B. Load Balancer zum App-Server oder Kommunikationen zwischen Diensten, können Pre-Fork-Systeme sehr erfolgreich sein. Das Hochfahren eines Prozesses zur Bearbeitung der Anforderung ist kostenlos, und ein einzelner Prozess kann für die Bearbeitung einer einzelnen Anforderung reserviert werden. Das Eliminieren dieser Dinge kann zu einem insgesamt schnelleren und effizienteren System führen, bis die Anzahl der gleichzeitigen Verbindungen die Anzahl der verfügbaren Prozesse übersteigt, um diese abzuwickeln.
In Ihrer Situation haben Sie es mit Clients mit hoher Latenz über das Internet zu tun. Diese langsamen Clients können dieselben Prozesse verbinden. Wenn es auf QPS ankommt, muss der Anwendungscode die Anforderung so schnell wie möglich empfangen, verarbeiten und auflösen, damit er zu einer anderen Anforderung wechseln kann. Wenn langsame Clients direkt mit Ihrem System kommunizieren, binden sie diesen Prozess zusammen und verlangsamen ihn. Anstatt die Anfrage so schnell wie möglich zu bearbeiten und zu entsorgen, muss dieser Prozess nun auch auf den langsamen Client warten. Effektives QPS sinkt.
Asynchrone Server wie Nginx können eine große Anzahl von Verbindungen mit sehr geringen CPU- und Speicherkosten verarbeiten. Sie werden von langsamen Clients nicht in der gleichen Weise negativ beeinflusst, da sie in der Lage sind, eine große Anzahl von Clients gleichzeitig zu behandeln. Im Falle von Nginx können mit moderner Hardware Zehntausende von Verbindungen gleichzeitig verarbeitet werden.
Nginx vor einem Pre-Forking-Server ist eine großartige Kombination. Nginx kümmert sich um die Kommunikation mit Kunden und wird für die Behandlung langsamer Kunden nicht bestraft. Es sendet Anforderungen an das Backend, so schnell das Backend diese Anforderungen verarbeiten kann, sodass das Backend so effizient wie möglich mit Serverressourcen umgehen kann. Das Backend gibt das Ergebnis zurück, sobald es es berechnet hat, und Nginx puffert diese Antwort, um langsamen Clients in ihrem eigenen Tempo den Feed zu geben. Währenddessen kann das Backend eine weitere Anfrage bearbeiten, auch wenn der langsame Client das Ergebnis noch empfängt.
@blueben ist richtig. Ein spezifisches und weit verbreitetes Beispiel dafür, was passieren kann, wenn ein Reverse-Proxy nicht verwendet wird, ist, dass eine Back-End-Datenbank Datenbankverbindungs-Handles ausführen kann, bei denen kein Proxy vorhanden ist und eine Verkehrsspitze auftritt. Dies liegt daran, dass die Verbindungen nur langsam freigegeben werden, wie in @blueben beschrieben.
Ein erster Instinkt, um zu sehen, dass die Datenbankhandles ausgehen, könnte darin bestehen, mehr Datenbankverbindungen zu unterstützen. Durch Hinzufügen eines Reverse-Proxys vor der App wird jedoch die Anzahl der für hohe Auslastung erforderlichen Datenbankverbindungen erheblich gesenkt und stabilisiert - die Datenbankverbindungsebene steigt bei einem Anstieg des Datenverkehrs nicht annähernd so stark an.
Nginx eignet sich auch hervorragend zum Bereitstellen statischer Inhalte, zum Zwischenspeichern und für verschiedene andere HTTP-Aufgaben, sodass sich Ihr App-Server darauf konzentriert, ein App-Server zu sein.