Probleme mit nginx limit_req rate-limiting - docs Klärung?

Bin ich ohne Ende Mühe, rate limiting, um die Arbeit auf nginx mit passenger/rails.

Teil der Verwirrung kommt mit der Unterscheidung zwischen denen Aspekte der config arbeiten, auf einer pro-client-basis und die globalen Grenzen.

Habe ich Probleme, immer meinen Kopf um das ideale setup für nginx ist limit_req und limit_req_zone configs. Es scheint vage flip-flop zwischen Sprache deutet an, dass dies entweder Benutzer-spezifische oder gilt weltweit.

In der Dokumente-es ist ziemlich vage, wie genau die limit_req_zone - Linie arbeitet. Ist diese 'zone' Globale oder pro Benutzer? Angesichts der folgenden Zeile gehe ich Recht in der folgenden Schlussfolgerungen:

limit_req_zone $binary_remote_addr zone=update_requests:1m rate=20r/s;

1. $binary_remote_addr stellt ein Benutzer die IP-Adresse
2. Diese Darstellung ist insbesondere vorzuziehen, da es weniger Speicherplatz verbraucht als $remote_addr? Warum ist das wichtig oder vorzuziehen?
3. Die 'zone' (in diesem Fall) ist gefüllt mit Darstellungen Ihrer IP-Adresse...?
4. 'rate' die rate, mit der Anfragen dürfen die Warteschlange verlassen?
5. Diese 'bewerten' und 'zone' - sind Sie client-spezifisch oder global???

Ich bin mir auch unsicher über die limit_req Linie, z.B. diese:

limit_req zone=main_site burst=10 nodelay;

1. Nicht ganz sicher, was burst bedeutet. Die docs sind vage, auch hier. Ich denke, das ist eine Anzahl von Anfragen. Warum die Anzahl der Anforderungen, wenn der rest der Anträge-system verwendet diese bizarre "zone" - system?
2. 'burst' - Anfragen sind per....welcher Zeitrahmen?
3. 'nodelay', soweit ich das verstanden habe, soll dazu dienen, einen 503-Fehler sofort, wenn Sie haben andere Aufträge in der Warteschlange, anstatt zu warten, für die Warteschlange zu beenden. a) warten, wie lange? b) bedeutet dies, dass die 'burst' - Einstellung wird in diesem Fall ignoriert?

Dank.

---

Einige hintergrund-Infos für den Fall, jemand ist wirklich gelangweilt und will haben Sie einen Blick auf die config und die Allgemeinen Probleme, die wir versuchen zu lösen:

Im moment habe ich dies (Auszug):

limit_req_zone $binary_remote_addr zone=main_site:10m rate=40r/s;
limit_req_zone $binary_remote_addr zone=update_requests:1m rate=20r/s;

server {
  listen        80;
  server_name   [removed];
  root          [removed];
  include       rtmp_proxy_settings;

  try_files $uri /system/maintenance.html @passenger;
  location @passenger {
    passenger_max_request_queue_size 0; # 256;
    limit_rate_after 2048k;
    limit_rate 512k;
    limit_req zone=main_site burst=10 nodelay;
    limit_conn addr 5;
    passenger_enabled on;
    passenger_min_instances 3;
  }

  location ~ ^/update_request {
    passenger_enabled on;
    limit_req zone=update_requests burst=5 nodelay;
  }


  gzip on;
  gzip_min_length 1000;
  gzip_proxied expired no-cache no-store private auth;
  gzip_types text/plain application/xml application/javascript text/javascript text/css;
  gzip_disable "msie6";
  gzip_http_version 1.1;
}

Wir haben zwei Zonen definiert:

a) "main_site", entworfen, um alles zu fangen
b) "update_request", JS auf der client fragt diese via AJAX um den Inhalt zu aktualisieren, wenn Sie einen Zeitstempel in eine kleine (Cache) - Datei änderungen

Durch seine Natur dieser neigt dazu, bedeuten, dass wir ziemlich wenig traffic für 1 oder 2 Minuten, aber dann eine massive spike, wenn möglicherweise 10.000 clients alle auf dem server auf einmal für diese aktualisierte Inhalte (serviert aus der DB in einer etwas anderen Weise, je nach Filter, Zugriffsrechte, etc)

Waren wir zur Feststellung, dass in Zeiten der schweren Last wurde die Website Schleifen zum Stillstand, wenn die CPU-Kerne wurden ausgereizt - wir hatten einige Fehler in unserem Update-code, der bedeutete, dass, wenn die Verbindung fallen gelassen wurde, die Abfragen in eine Warteschlange gestellt und einfach gehalten, der Versumpfung der server down, bis wir hatten die site temporär down und zwingen die Benutzer Abmelden und den browser aktualisieren... effektiv wir DDoS würde uns 😛 ich denke, das war ursprünglich verursacht durch einige Verbindungsprobleme, die auf unserem hosting-Unternehmens-Seite, wodurch sich eine Reihe von Anforderungen an die Warteschlange bis in den browser des Benutzers.

Während wir ausgebügelt die Fehler, die wir gewarnt Kunden, dass Sie möglicherweise die ungeraden 503 "schweren Last" - Nachricht oder den Inhalt nicht aktualisieren, in eine rechtzeitige fashion. Die ursprüngliche Absicht der geschwindigkeitsbestimmende wurde, um sicherzustellen, dass die alltäglichen Seiten der Website könnte sich weiter navigiert werden um auch während der schweren Last, während die rate begrenzt den aktualisierten Inhalt.

Jedoch die wichtigste Frage, die wir jetzt sehen ist, dass selbst nach den bugs in der Update-code wurde (hoffentlich) ausgemerzt, wir können einfach nicht schlagen eine gute balance auf die limitierenden Faktoren. Alles, was wir setzen scheint, erzeugen eine ungesunde Zahl der 503-Fehler in der access-logs, Wann immer ein neues Stück von Inhalten wird Hinzugefügt, um die Website (und zog durch unsere Nutzer alle auf einmal)

Suchen wir an verschiedenen Lösungen, die hier in Bezug auf die Zwischenspeicherung, sondern im Idealfall würden wir gerne noch geschützt werden durch irgendeine Art von rate-limiting, das hat keine Auswirkungen auf die Benutzer im alltäglichen Betrieb.