☰

NGINX: Request-Limit-Timeout-Verhalten für Abfragen in der Warteschlange (Burst)

tag-icon • tag-icon nginx reverse-proxy high-load 503-error http-status-code-408
NGINX: Request-Limit-Timeout-Verhalten für Abfragen in der Warteschlange (Burst)

Derzeit haben wir eine Warteschlangengröße von 3000 Anfragen.

location /api/v2 {
     limit_req zone=bursted burst=3000;
     include /etc/nginx/proxy.conf;
 }

Die Ratenbegrenzung beträgt 10 Anfragen pro Sekunde.

 limit_req_zone $limit zone=api_slow:10m rate=1r/s;
 limit_req_zone $server_name zone=bursted:10m rate=10r/s;

Das Keep-Alive-Timeout beträgt 30 Sekunden. Mit anderen Worten: Alle 30 Sekunden sollten 2700 Anfragen mit dem Fehlercode 408 abgelehnt werden, wenn die Warteschlange voll ist.

 reset_timedout_connection on;
 client_body_timeout 10;
 send_timeout 2;
 keepalive_timeout 30;

In Stoßzeiten konnte ich in den Protokollen keine Anfrage finden, die von NGINX aufgrund eines Timeouts mit dem Fehlercode 408 abgelehnt wurde, während die Anfrage in der Warteschlange auf die Weiterleitung an den Servlet-Container wartete. Es erfolgte nur eine Ablehnung mit dem Fehlercode 503, was dem Overhead der Anfragerate entspricht.

delaying request, excess: 2958.320, by zone "bursted"
limiting requests, excess: 3000.730 by zone "bursted"

Lehnt NGINX Anfragen in solchen Warteschlangen per Timeout ab, wenn sie zu lange hängen? Was ist dieses Timeout? Wo ist seine Konfiguration?

Antwort1

Es scheint, dass es eine gewisse Verwirrung darüber gibt, wie die Ratenbegrenzung und Timeouts bei Nginx funktionieren. Es gibt keineAuszeitzur Ratenbegrenzung. Sie legen einfach eine Rate und eine Warteschlangengröße fest. Alle Anfragen, die die Rate überschreiten, werden der Warteschlange hinzugefügt, um später verarbeitet zu werden. Sobald die Warteschlange vollständig gefüllt ist, wird jede weitere Anfrage mit einem 503-Statuscode abgelehnt.

In Ihrem BeispielSie haben eine Rate von 10 Anfragen pro Sekunde (10r/s), eine Burst-Größe von 3000 und eine Zone mit einer Größe von 10 Megabyte „geburstet“. Und diese Ratenbegrenzung gilt als separate Zählung für jeden definierten Server.

Mit anderen Worten: Ihr Server akzeptiert und verarbeitet alle 0,1 Sekunde eine Anfrage und kann bis zu 3000 weitere Anfragen in die Warteschlange stellen, die dann mit der definierten Rate verarbeitet werden: eine alle 0,1 Sekunde. Und Ihre Burst-Zone kann etwa 160.000 IP-Adressen speichern.

Das bedeutetWenn innerhalb einer Sekunde 3011 Anfragen eingehen, verarbeitet nginx die ersten 10 Anfragen sofort, stellt weitere 3000 Anfragen in die Warteschlange und die 3011. Anfrage wird mit einem 503-Statuscode abgelehnt. Die Warteschlange wird dann mit der definierten Rate von einer Anfrage alle 0,1 Sekunden verarbeitet. Solange keine neuen Anfragen eingehen, wird die Warteschlange kürzer und es können wieder neue Anfragen zur Warteschlange hinzugefügt werden. Aber solange die Warteschlange bereits 3000 Anfragen enthält, wird jede weitere Anfrage mit einem 503-Statuscode abgelehnt.

Dieses Verhalten der linearen Verarbeitung der Burst-Warteschlange kann dazu führen, dass Ihre Site langsam erscheint. Um dies zu verhindern, können Sie den nodelayParameter zu hinzufügen limit_req zone=bursted burst=3000 nodelay;. Dadurch werden alle Anfragen aus Ihrer Burst-Warteschlange sofort verarbeitet, während die Slots in der Warteschlange als „belegt“ markiert und dann Slot für Slot mit der definierten Rate wieder „freigegeben“ werden, sodass die definierte Ratenbegrenzung im Laufe der Zeit eingehalten wird.

Übrigens: Sie können den Statuscode für abgelehnte Anfragen von 503 auf 444 ändern, indem Sie ihn limit_req_status 444;zu Ihrem httpKonfigurationsblock hinzufügen.

Weitere Einzelheiten finden Sie unter:

Die beiden Timeouts aus Ihrer Konfiguration:

Dadurch client_body_timeout 10;wartet Ihr Server bis zu 10 Sekunden, bis nach einer Anfrage ein Client-Body gesendet wird. Wenn innerhalb dieser Zeit kein Body vom Client gesendet wird, schließt der Server die Verbindung mit einem 408-Statuscode.

Dadurch keepalive_timeout 30;schließt Ihr Server nach 30 Sekunden jede noch offene Verbindung zu einem Client. Aber meinen Tests zufolge zählt die Zeit, die eine Anfrage in der Burst-Warteschlange wartet, nicht für das Keepalive_Timeout.

Durchführen von BelastungstestsmitaboderBelagerung.

verwandte Informationen