Prefácio
Eu tenho ajustado o HAProxy por um tempo e fiz muitos testes de desempenho nele. De 100 solicitações HTTP / s para 50.000 solicitações HTTP / s.
O primeiro conselho é ativar a página de estatísticas no HAProxy . Você precisa de monitoramento, sem exceção. Você também precisará de um ajuste fino se pretende ultrapassar 10.000 solicitações / s.
Os tempos limite são uma besta confusa porque eles têm uma enorme gama de valores possíveis, a maioria deles não tem diferenças observáveis. Eu ainda tenho que ver algo falhar por causa de um número 5% menor ou 5% maior. 10000 vs 11000 milissegundos, quem se importa? Provavelmente não é o seu sistema.
Configuração
Eu não posso, em boa consciência, dar alguns números como "melhores tempos de espera para todos".
O que posso dizer, em vez disso, são os tempos de espera MAIS agressivos, que são sempre aceitáveis para o balanceamento de carga HTTP (S). Se você encontrar menos que isso, é hora de reconfigurar seu balanceador de carga.
timeout connect 5000
timeout check 5000
timeout client 30000
timeout server 30000
Cliente de tempo limite
:
The inactivity timeout applies when the client is expected to acknowledge or
send data. In HTTP mode, this timeout is particularly important to consider
during the first phase, when the client sends the request, and during the
response while it is reading data sent by the server.
Leitura : este é o tempo máximo para receber cabeçalhos de solicitação HTTP do cliente.
3G / 4G / 56k / satellite pode ser lento às vezes. Ainda assim, eles devem ser capazes de enviar cabeçalhos HTTP em alguns segundos, NÃO 30.
Se alguém tiver uma conexão tão ruim que precise de mais de 30s para solicitar uma página (mais de 10 * 30s para solicitar as 10 imagens incorporadas / CSS / JS), acredito que seja aceitável rejeitá-lo.
servidor de tempo limite:
The inactivity timeout applies when the server is expected to acknowledge or
send data. In HTTP mode, this timeout is particularly important to consider
during the first phase of the server's response, when it has to send the
headers, as it directly represents the server's processing time for the
request. To find out what value to put there, it's often good to start with
what would be considered as unacceptable response times, then check the logs
to observe the response time distribution, and adjust the value accordingly.
Leitura : este é o tempo máximo para receber a resposta HTTP cabeçalhos do servidor (após receber a solicitação completa do cliente). Basicamente, este é o tempo de processamento de seus servidores, antes de começar a enviar a resposta.
Se o seu servidor for tão lento que seja necessário mais de 30s para começar a responder, então acredito que seja aceitável considerá-lo morto.
Caso especial : alguns serviços RARE que executam processamento muito pesado podem levar um minuto ou mais para fornecer uma resposta. Esse tempo limite pode precisar aumentar muito para esse uso específico. (Nota: É provável que seja um caso de design incorreto, use uma comunicação de estilo assíncrono ou não use HTTP.)
tempo limite de conexão:
Set the maximum time to wait for a connection attempt to a server to succeed.
Read : O tempo máximo que um servidor tem para aceitar uma conexão TCP.
Os servidores estão na mesma LAN que o HAProxy, então deve ser rápido. Dê pelo menos 5 segundos, porque é esse o tempo que pode demorar quando algo inesperado acontece (um pacote TCP perdido para retransmitir, um servidor bifurcando um novo processo para receber as novas solicitações, pico de tráfego).
Caso especial : quando os servidores estão em uma LAN diferente ou em um link não confiável. Esse tempo limite pode precisar ser aumentado muito. (Nota: Este é provavelmente um caso de arquitetura ruim.)
verificação de tempo limite:
Set additional check timeout, but only after a connection has been already
established.
Set additional check timeout, but only after a connection has been already
If set, haproxy uses min("timeout connect", "inter") as a connect timeout
for check and "timeout check" as an additional read timeout. The "min" is
used so that people running with very long "timeout connect" (eg. those
who needed this due to the queue or tarpit) do not slow down their checks.
(Please also note that there is no valid reason to have such long connect
timeouts, because "timeout queue" and "timeout tarpit" can always be used
to avoid that).
Read : Ao realizar uma verificação de integridade, o servidor tem timeout connect para aceitar a conexão e timeout check para fornecer a resposta.
Todos os servidores DEVEM ter uma verificação de integridade HTTP (S) configurada. Essa é a única maneira de o balanceador de carga saber se um servidor está disponível. A verificação de integridade é uma simples página /isalive respondendo sempre OK .
Dê esse tempo limite de pelo menos 5 segundos, porque esse é o tempo que pode demorar quando algo inesperado acontece (um pacote TCP perdido para restransmitir, um servidor bifurcando um novo processo para receber as novas solicitações, aumento de tráfego).
War Story : Muitas pessoas erroneamente acreditam que o servidor sempre pode responder a esta simples página em 3 ms. Eles definem um tempo limite agressivo (< 2000ms) com failover agressivo (2 verificações com falha = servidor inoperante). Eu vi sites inteiros indo por causa disso. Normalmente, há um ligeiro aumento no tráfego, os servidores backend ficam mais lentos, as verificações de integridade são atrasadas ... até que de repente todos eles terminam juntos, o HAProxy acha que TODOS os servidores morreram de uma só vez e todo o site está inativo.