Wie legen Sie beim Konfigurieren des HA-Proxys fest, welche Werte den Zeitüberschreitungen zugewiesen werden sollen? Ich habe ein halbes Dutzend Beispiele in verschiedenen Blogs gelesen, und jeder verwendet unterschiedliche Timeouts, und niemand diskutiert, warum.

HAProxy scheint sich insbesondere Sorgen um Client, Verbindung und Server zu machen, über die HAPRoxy eine Warnung ausgibt, wenn Sie die Einstellung vollständig aufheben:

While not properly invalid, you will certainly encounter various problems
with such a configuration. To fix this, please ensure that all following
timeouts are set to a non-zero value: 'client', 'connect', 'server'.

Die Dokumentation ist in dieser Hinsicht nicht hilfreich: Sie schlägt "etwas mehr als ein Vielfaches von 3 Sekunden" vor, aber nicht, warum Sie ein Vielfaches von 1 gegen 100 oder 42 wählen würden.

Das von mir verwendete RPM (Amazon Linux-Repository) legt die folgenden Standardeinstellungen fest:

timeout connect         10s
timeout client          1m
timeout server          1m

Zwei davon sind exakte Vielfache von 3 Sekunden und verstoßen gegen den einzigen offiziellen Rat, den ich gesehen habe.

Wenn Sie keinen speziellen Tuning-Rat haben, ist eine einfachere Frage vielleicht: Was kann ich bei sehr kurzen oder sehr langen Timeouts falsch machen?

Das TCP RTO (Receive Timeout) startet nach drei Sekunden. ( RFC 1122 ) Wenn für ein übertragenes Paket in dieser Zeit keine Bestätigung zurückgegeben wurde, wird davon ausgegangen, dass es verloren geht und erneut übertragen wird. Darauf bezieht sich der Autor mit ziemlicher Sicherheit. (Beachten Sie, dass das RTO außerhalb des Rahmens dieser Frage durch verschiedene Algorithmen dynamisch hoch- oder heruntergestimmt wird .)

Beachten Sie, dass dies wirklich nur für Verbindungen zwischen Ihrem Frontend-Server und den Clients (dh Webbenutzern) gilt. In normalen Szenarien sollten sich die Verbindungen zwischen HAProxy und Ihren Backend-Servern in einem LAN befinden und Sie sollten viel kürzere Timeouts verwenden, damit fehlerhafte Backends früher außer Betrieb genommen werden.

Einige Ihrer Webbenutzer haben möglicherweise Verbindungen mit sehr hoher Latenz, z. B. über Satellit, und werden aufgrund dessen möglicherweise häufiger als normal weitergeleitet. Die RTT auf einer Verbindung, auf der ein Satellit verwendet wird, kann 2000 ms überschreiten, auch wenn alles in Ordnung ist.

In Anbetracht dessen werden Sie im Allgemeinen sehr kurze timeout connectund sehr lange Auszeiten wünschen timeout client.

Für timeout serverhängt dies von Ihrer Web - Anwendung. Berücksichtigen Sie beim Festlegen des Zeitlimits die Komplexität der bereitgestellten Webanwendung und wie lange es im schlimmsten Fall dauern kann, eine komplexe Anforderung zu verarbeiten. Erhöhen Sie im Zweifelsfall den Wert.

Vorwort

Ich habe HAProxy für eine Weile optimiert und eine Menge Leistungstests durchgeführt. Von 100 HTTP-Anfragen / s bis 50 000 HTTP-Anfragen / s.

Der erste Rat ist, die Statistikseite auf HAProxy zu aktivieren . Sie MÜSSEN überwachen, keine Ausnahme. Sie müssen auch eine Feinabstimmung vornehmen, wenn Sie über 10.000 Anfragen / s hinausgehen möchten.

Zeitüberschreitungen sind ein verwirrendes Biest, da sie einen großen Bereich möglicher Werte aufweisen, von denen die meisten keinen beobachtbaren Unterschied aufweisen. Ich habe noch nicht gesehen, dass etwas wegen einer um 5% niedrigeren oder um 5% höheren Zahl fehlschlägt. 10000 vs 11000 Millisekunden, wen interessiert das? Wahrscheinlich nicht dein System.

Aufbau

Ich kann nicht mit gutem Gewissen ein paar Zahlen als "beste Auszeit für alle" angeben.

Was ich stattdessen feststellen kann, sind die aggressivsten Zeitüberschreitungen, die für den HTTP (S) -Lastausgleich immer akzeptabel sind. Wenn Sie auf einen niedrigeren Wert stoßen, müssen Sie Ihren Load Balancer neu konfigurieren.

timeout connect 5000
timeout check 5000
timeout client 30000
timeout server 30000

Timeout-Client:

Das Zeitlimit für Inaktivität gilt, wenn der Client Daten bestätigen oder senden soll. Im HTTP-Modus ist dieses Zeitlimit besonders wichtig, wenn der Client in der ersten Phase die Anforderung sendet und während der Antwort, während er die vom Server gesendeten Daten liest.

Lesen Sie : Dies ist die maximale Zeit zu empfangen HTTP - Request - Header aus dem Client.

3G / 4G / 56k / Satellit kann manchmal langsam sein. Dennoch sollten sie in der Lage sein, HTTP-Header in wenigen Sekunden zu senden, NICHT in 30 Sekunden.

Wenn jemand eine so schlechte Verbindung hat, dass er mehr als 30 Sekunden benötigt, um eine Seite anzufordern (dann mehr als 10 * 30 Sekunden, um die 10 eingebetteten Bilder / CSS / JS anzufordern), halte ich es für akzeptabel, ihn abzulehnen.

Timeout-Server:

Das Zeitlimit für Inaktivität gilt, wenn der Server Daten bestätigen oder senden soll. Im HTTP-Modus ist dieses Zeitlimit besonders wichtig, wenn in der ersten Phase der Serverantwort die Header gesendet werden müssen, da es direkt die Verarbeitungszeit des Servers für die Anforderung darstellt. Um herauszufinden, welchen Wert Sie dort eingeben müssen, sollten Sie häufig mit nicht akzeptablen Antwortzeiten beginnen. Überprüfen Sie dann die Protokolle, um die Verteilung der Antwortzeiten zu beobachten, und passen Sie den Wert entsprechend an.

Lesen : Dies ist die maximale Zeit, um HTTP- Antwortheader vom Server zu empfangen (nachdem die vollständige Clientanforderung empfangen wurde). Grundsätzlich ist dies die Verarbeitungszeit von Ihren Servern, bevor die Antwort gesendet wird.

Wenn Ihr Server so langsam ist, dass er mehr als 30 Sekunden benötigt, um eine Antwort zu geben, ist es meines Erachtens akzeptabel, ihn für tot zu halten.

Sonderfall : Bei einigen RARE-Diensten kann es eine ganze Minute oder länger dauern, bis eine Antwort vorliegt. Dieses Zeitlimit muss für diese spezielle Verwendung möglicherweise erheblich erhöht werden. (Hinweis: Dies ist wahrscheinlich ein Fall von schlechtem Design. Verwenden Sie eine asynchrone Kommunikation oder verwenden Sie überhaupt kein HTTP.)

Timeout-Verbindung:

Legen Sie die maximale Wartezeit für einen erfolgreichen Verbindungsversuch zu einem Server fest.

Lesen : Die maximale Zeit, die ein Server benötigt, um eine TCP-Verbindung zu akzeptieren.

Server befinden sich im selben LAN wie HAProxy, daher sollte es schnell sein. Warten Sie mindestens 5 Sekunden, da es so lange dauern kann, bis etwas Unerwartetes passiert (ein verlorenes TCP-Paket zum erneuten Übertragen, ein Server, der einen neuen Prozess veranlasst, die neuen Anforderungen entgegenzunehmen, Anstieg des Datenverkehrs).

Sonderfall : Wenn sich Server in einem anderen LAN oder über eine unzuverlässige Verbindung befinden. Dieses Zeitlimit muss möglicherweise erheblich erhöht werden. (Hinweis: Dies ist wahrscheinlich ein Fall von schlechter Architektur.)

Timeout-Check:

Legen Sie ein zusätzliches Zeitlimit für die Prüfung fest, jedoch erst, nachdem bereits eine Verbindung hergestellt wurde.

Zusätzliches Zeitlimit für die Prüfung festlegen, aber erst, nachdem bereits eine Verbindung hergestellt wurde Wenn dies festgelegt wurde, verwendet haproxy min ("Zeitlimit für Verbindung", "inter") als Verbindungszeitlimit für die Prüfung und "Zeitlimit für Prüfung" als zusätzliches Zeitlimit für das Lesen. Die "min" wird verwendet, damit Leute, die mit sehr langer "Zeitüberschreitung" verbunden sind (z. B. diejenigen, die dies aufgrund der Warteschlange oder der Plane benötigten), ihre Prüfungen nicht verlangsamen. (Bitte beachten Sie auch, dass es keinen gültigen Grund für so lange Verbindungs-Timeouts gibt, da "Timeout-Warteschlange" und "Timeout-Tarpit" immer verwendet werden können, um dies zu vermeiden.)

Lesen : Wenn ein Healthcheck durchgeführt wird, muss der Server timeout connectdie Verbindung akzeptieren und dann timeout checkdie Antwort geben.

Für alle Server MUSS eine HTTP (S) -Zustandsüberprüfung konfiguriert sein. Nur so kann der Load Balancer feststellen, ob ein Server verfügbar ist. Der Healthcheck ist eine einfache /isaliveSeite, die immer antwortet OK.

Geben Sie diesem Timeout mindestens 5 Sekunden, da es so lange dauern kann, bis etwas Unerwartetes passiert (ein verlorenes TCP-Paket zum erneuten Übertragen, ein Server, der einen neuen Prozess veranlasst, die neuen Anforderungen entgegenzunehmen, Anstieg des Datenverkehrs).

Kriegsgeschichte : Viele Leute glauben fälschlicherweise , dass der Server diese einfache Seite immer in 3 ms beantworten kann. Sie setzen ein aggressives Timeout (<2000 ms) mit aggressivem Failover (2 fehlgeschlagene Prüfungen = Server tot). Ich habe gesehen, wie ganze Websites deswegen herunterfielen. Normalerweise kommt es zu einem leichten Anstieg des Datenverkehrs, die Back-End-Server werden langsamer, die Integritätsprüfungen werden verzögert ... bis plötzlich alle zusammen eine Zeitüberschreitung verzeichnen.