Quando si configura il proxy HA, come si decide quali valori assegnare ai timeout? Ho letto una mezza dozzina di campioni in vari blog e tutti usano timeout diversi e nessuno ne discute il perché.

HAProxy sembra particolarmente preoccupato per client, connessione e server, di cui HAPRoxy emette un avviso se si lascia completamente non impostato:

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'.

La documentazione non è utile a questo proposito: suggerisce "leggermente al di sopra dei multipli di 3 secondi", ma non il motivo per cui si dovrebbe scegliere un multiplo di 1 vs 100 o 42.

L'RPM che sto usando (repository Amazon Linux) imposta queste impostazioni predefinite:

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

Due dei quali sono esatti multipli di 3 secondi, violando l'unico consiglio ufficiale che ho visto.

Se non hai consigli di ottimizzazione specifici, forse una domanda più semplice è: cosa dovrei aspettarmi di sbagliare con timeout davvero brevi o molto lunghi?

Il TCP RTO (timeout di ricezione) inizia a tre secondi. ( RFC 1122 ) Se un pacchetto trasmesso non ha ricevuto una conferma in quel momento, si presume che sia perso e ritrasmesso. Questo è quasi certamente ciò a cui l'autore si riferisce. (Si noti che l'RTO viene sintonizzato su o giù dinamicamente da vari algoritmi , al di fuori dell'ambito di questa domanda.)

Tieni presente che ciò si applica solo alle connessioni tra il tuo server front-end e i client (ovvero gli utenti Web). In scenari normali, le connessioni tra HAProxy e i server back-end dovrebbero essere su una LAN e si dovrebbero usare timeout molto più brevi, in modo che i back-end malfunzionanti vengano messi fuori servizio prima.

Per quanto riguarda gli utenti Web, alcuni di essi potrebbero trovarsi su connessioni a latenza molto elevata, come i satelliti, e potrebbero verificarsi ritrasmissioni più elevate del normale a causa di ciò. L'RTT su una connessione in cui è in uso un satellite può superare i 2000 ms anche se tutto va bene.

Con tutto questo in mente, generalmente vorrai timeout molto brevi per timeout connectquelli molto lunghi timeout client.

Per timeout server, questo dipende dalla tua applicazione web. Quando si imposta il timeout, considerare la complessità dell'app Web offerta e il tempo che potrebbe richiedere, nel peggiore dei casi, per elaborare una richiesta complessa. In caso di dubbio, aumentare il valore.

Prefazione

Ho messo a punto HAProxy per un po 'e ho fatto molti test delle prestazioni su di esso. Da 100 richieste HTTP a 50.000 richieste HTTP.

Il primo consiglio è di abilitare la pagina delle statistiche su HAProxy . BISOGNA monitorare, nessuna eccezione. Avrai anche bisogno di una messa a punto se intendi andare oltre 10.000 richieste / e.

I timeout sono una bestia confusa perché hanno una vasta gamma di possibili valori, molti dei quali non hanno differenze osservabili. Devo ancora vedere qualcosa fallire a causa di un numero inferiore del 5% o superiore del 5%. 10000 vs 11000 millisecondi, a chi importa? Probabilmente non il tuo sistema.

Configurazione

In buona coscienza non posso dare un paio di numeri come "i migliori timeout di sempre per tutti".

Quello che posso dire invece sono i timeout PIÙ aggressivi che sono sempre accettabili per il bilanciamento del carico HTTP (S). Se si riscontrano livelli inferiori a questi, è tempo di riconfigurare il bilanciamento del carico.

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

client di timeout:

Il timeout di inattività si applica quando ci si aspetta che il client riconosca o invii dati. In modalità HTTP, questo timeout è particolarmente importante da considerare durante la prima fase, quando il client invia la richiesta e durante la risposta durante la lettura dei dati inviati dal server.

Leggi : questo è il tempo massimo per ricevere le intestazioni delle richieste HTTP dal client.

3G / 4G / 56k / satellite a volte può essere lento. Tuttavia, dovrebbero essere in grado di inviare le intestazioni HTTP in pochi secondi, NON 30.

Se qualcuno ha una connessione così grave da richiedere più di 30 secondi per richiedere una pagina (quindi più di 10 * 30 secondi per richiedere le 10 immagini incorporate / CSS / JS), credo che sia accettabile rifiutarlo.

server di timeout:

Il timeout di inattività si applica quando si prevede che il server riconosca o invii i dati. In modalità HTTP, questo timeout è particolarmente importante da considerare durante la prima fase della risposta del server, quando deve inviare le intestazioni, poiché rappresenta direttamente il tempo di elaborazione del server per la richiesta. Per scoprire quale valore mettere lì, spesso è bene iniziare con quelli che sarebbero considerati tempi di risposta inaccettabili, quindi controllare i log per osservare la distribuzione dei tempi di risposta e regolare il valore di conseguenza.

Leggi : questo è il tempo massimo per ricevere le intestazioni di risposta HTTP dal server (dopo aver ricevuto la richiesta client completa). Fondamentalmente, questo è il tempo di elaborazione dai tuoi server, prima che inizi a inviare la risposta.

Se il tuo server è così lento da richiedere più di 30 secondi per iniziare a dare una risposta, allora credo che sia accettabile considerarlo morto.

Caso speciale : alcuni servizi RARE che eseguono elaborazioni molto pesanti potrebbero richiedere un minuto o più per rispondere. Potrebbe essere necessario aumentare molto questo timeout per questo specifico utilizzo. (Nota: è probabile che questo sia un caso di cattiva progettazione, utilizzare una comunicazione in stile asincrono o non usare affatto HTTP.)

timeout connettersi:

Impostare il tempo massimo di attesa per il successo di un tentativo di connessione a un server.

Leggi : il tempo massimo che un server deve accettare una connessione TCP.

I server sono nella stessa LAN di HAProxy, quindi dovrebbe essere veloce. Dagli almeno 5 secondi perché è il tempo che può impiegare quando accade qualcosa di inaspettato (un pacchetto TCP perso da ritrasmettere, un server che richiede un nuovo processo per accettare le nuove richieste, aumentare il traffico).

Caso speciale : quando i server si trovano in una LAN diversa o su un collegamento non affidabile. Potrebbe essere necessario aumentare molto questo timeout. (Nota: è probabile che questo sia un caso di cattiva architettura.)

controllo del timeout:

Imposta un timeout di controllo aggiuntivo, ma solo dopo aver già stabilito una connessione.

Imposta il timeout di controllo aggiuntivo, ma solo dopo che è già stata stabilita una connessione Se impostato, haproxy utilizza min ("timeout connect", "inter") come timeout di connessione per il check e "timeout check" come timeout di lettura aggiuntivo. Il "min" viene utilizzato in modo tale che le persone che eseguono un "timeout connect" molto lungo (ad es. Coloro che ne avevano bisogno a causa della coda o del tarpit) non rallentassero i loro controlli. (Si noti inoltre che non esiste un motivo valido per avere timeout di connessione così lunghi, poiché "coda di timeout" e "tarpit di timeout" possono sempre essere utilizzati per evitarlo).

Leggi : quando si esegue un controllo di integrità, il server deve timeout connectaccettare la connessione timeout checke fornire la risposta.

Tutti i server DEVONO avere un controllo di integrità HTTP (S) configurato. Questo è l'unico modo per il bilanciamento del carico di sapere se un server è disponibile. Healthcheck è una /isalivepagina semplice che risponde sempre OK.

Concedi questo timeout almeno 5 secondi perché è il tempo che può impiegare quando accade qualcosa di inaspettato (un pacchetto TCP perso da ritrasferire, un server che richiede un nuovo processo per accettare le nuove richieste, un picco nel traffico).

War Story : Molte persone credono erroneamente che il server possa sempre rispondere a questa semplice pagina in 3 ms. Hanno impostato un timeout aggressivo (<2000 ms) con failover aggressivo (2 controlli non riusciti = server guasto). Ho visto interi siti web andare giù per questo. In genere c'è un leggero picco nel traffico, i server back-end rallentano, i controlli di salute sono in ritardo ... fino a quando all'improvviso si interrompono tutti insieme, HAProxy pensa che TUTTI i server siano morti in una sola volta e l'intero sito non funziona.