Keepalive-Einstellung für Gunicorn hinter ELB ohne Nginx

Die REST-API unserer App wird von Gunicorn ( nicht hinter Nginx) bereitgestellt, das auf AWS EC2-Instanzen mit einem typischen Setup für automatische Skalierung / Lastenausgleich ausgeführt wird. Das Leerlauf-Timeout des Load Balancers beträgt 60 Sekunden und das Keep-Alive-Timeout von Gunicorn 2 Sekunden. Wir haben sporadische 504 Gateway TimeoutAntworten von dieser Konfiguration gesehen. Laut Amazon-Dokumenten kann dies daran liegen, dass das Keep-Alive-Timeout des Servers niedriger ist als die Leerlauf-Timeout-Einstellung des Load Balancers:

Ursache 2: Registrierte Instanzen, die die Verbindung zu Elastic Load Balancing schließen.

Lösung 2: Aktivieren Sie die Keep-Alive-Einstellungen für Ihre EC2-Instanzen, und legen Sie das Keep-Alive-Timeout auf einen Wert fest, der größer oder gleich den Einstellungen für das Leerlauf-Timeout Ihres Load Balancers ist.

Bei Nginx keepalive_timeoutbeträgt der Standardwert 75 Sekunden, was anscheinend gut mit den ELB-Standardeinstellungen zusammenarbeitet. Allerdings Gunicorn docs empfehlen eine keepaliveEinstellung im Bereich von 1-5 Sekunden.

Ist es sinnvoll, Gunicorns Keepalive auf 75 Sekunden zu erhöhen, oder gibt es einen guten Grund, es unter 5 Sekunden zu halten, obwohl wir keinen Reverse-Proxy verwenden?

Sie werden mit ziemlicher Sicherheit den Keepalive-Timer gemäß der ELB-Empfehlung erhöhen wollen, da ELB Verbindungen wiederverwendet. Sie werden so lange gespeichert, bis das Zeitlimit abgelaufen ist. Wenn eine andere Anforderung bei der ELB eingeht, wird diese häufig über eine der bereits offenen Verbindungen an Sie gesendet.

504 Gateway Timeout ist ein merkwürdiger Fehler für diesen Zustand, aber es scheint, dass ELB diesen zurückgibt, wenn die Wiederverwendung einer Verbindung mit dem vorzeitigen Schließen des Back-Ends zusammenfällt.

Die 5-Sekunden-Empfehlung ist möglicherweise sinnvoll, wenn die Browser direkt mit dem Back-End kommunizieren. Bei ELB ist dies jedoch nicht der Fall. Dies ist selbst ein geeigneter Reverse-Proxy, wenn der HTTP-Modus ausgeführt wird.