Ao configurar o Proxy HA, como você decide quais valores atribuir aos tempos limite? Eu li meia dúzia de amostras em vários blogs e todo mundo usa tempos limite diferentes e ninguém discute o porquê.

O HAProxy parece especificamente preocupado com o cliente, a conexão e o servidor, sobre os quais o HAPRoxy lança um aviso se você deixar completamente desmarcado:

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

A documentação é inútil a esse respeito: sugere "um pouco acima de múltiplos de 3 segundos", mas não por que você escolheria um múltiplo de 1 vs 100 ou 42.

O RPM que estou usando (repositório Amazon Linux) define esses padrões:

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

Dois dos quais são múltiplos exatos de 3 segundos, violando o único conselho oficial que eu já vi.

Se você não tem conselhos específicos de ajuste, talvez uma pergunta mais fácil seja: o que devo esperar dar errado com intervalos muito curtos ou muito longos?

O TCP RTO (tempo limite de recebimento) inicia em três segundos. ( RFC 1122 ) Se um pacote transmitido não tiver recebido um reconhecimento nesse período, será considerado perdido e retransmitido. É quase certamente a que o autor está se referindo. (Observe que o RTO é ajustado para cima ou para baixo dinamicamente por vários algoritmos , fora do escopo desta pergunta.)

Lembre-se de que isso realmente se aplica apenas às conexões entre o servidor front-end e os clientes (ou seja, usuários da web). Em cenários normais, as conexões entre o HAProxy e os servidores de back-end devem estar em uma LAN e você deve usar tempos limite muito mais curtos, para que os back-ends com defeito sejam retirados de serviço mais cedo.

Quanto aos usuários da Web, alguns deles podem estar em conexões de latência muito alta, como satélite, e podem sofrer retransmissões acima do normal devido a isso. O RTT em uma conexão em que um satélite está em uso pode exceder 2000 ms, mesmo que esteja tudo bem.

Com tudo isso em mente, você geralmente desejará intervalos muito curtos timeout connecte longos timeout client.

Pois timeout server, isso depende do seu aplicativo da web. Ao definir o tempo limite, considere a complexidade do aplicativo da Web que está sendo veiculado e quanto tempo pode levar no pior caso para processar uma solicitação complexa. Em caso de dúvida, aumente o valor.

Prefácio

Estive ajustando o HAProxy por um tempo e fiz muitos testes de desempenho. De 100 solicitações / s HTTP a 50.000 solicitações / s HTTP.

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 pretender passar de 10.000 solicitações / s.

Timeouts são um animal confuso, porque eles têm uma enorme variedade de valores possíveis, a maioria deles sem diferença observável. Ainda estou para 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

Não posso, em sã consciência, dar alguns números como "os melhores tempos de todos os tempos".

O que eu posso dizer são os tempos limite mais agressivos, sempre aceitáveis ​​para o balanceamento de carga HTTP (S). Se você encontrar um valor inferior a estes, é hora de reconfigurar seu balanceador de carga.

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

cliente de tempo limite:

O tempo limite de inatividade se aplica quando se espera que o cliente reconheça ou envie dados. No modo HTTP, esse tempo limite é particularmente importante a considerar durante a primeira fase, quando o cliente envia a solicitação e durante a resposta enquanto está lendo os dados enviados pelo servidor.

Leitura : este é o tempo máximo para receber cabeçalhos de solicitação HTTP do cliente.

Às vezes, o 3G / 4G / 56k / satélite pode ser lento. Ainda assim, eles devem poder enviar cabeçalhos HTTP em alguns segundos, NÃO 30.

Se alguém tem uma conexão tão ruim que precisa 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:

O tempo limite de inatividade se aplica quando se espera que o servidor reconheça ou envie dados. No modo HTTP, esse tempo limite é particularmente importante a considerar durante a primeira fase da resposta do servidor, quando ele deve enviar os cabeçalhos, pois representa diretamente o tempo de processamento do servidor para a solicitação. Para descobrir qual valor colocar lá, geralmente é bom começar com o que seria considerado como tempos de resposta inaceitáveis, depois verifique os logs para observar a distribuição do tempo de resposta e ajuste o valor de acordo.

Ler : é o tempo máximo para receber cabeçalhos de resposta HTTP do servidor (depois de receber a solicitação completa do cliente). Basicamente, esse é o tempo de processamento dos seus servidores, antes que ele comece a enviar a resposta.

Se seu servidor é tão lento que requer mais de 30 anos para começar a dar uma resposta, acredito que seja aceitável considerá-lo morto.

Caso especial : alguns serviços RAROS que executam processamento muito pesado podem levar um minuto ou mais para dar uma resposta. Esse tempo limite pode precisar ser muito aumentado para esse uso específico. (Nota: é provável que este seja um caso de design incorreto, use uma comunicação de estilo assíncrono ou não use HTTP.)

timeout connect:

Defina o tempo máximo para aguardar uma tentativa de conexão com um servidor.

Leitura : o tempo máximo que um servidor tem para aceitar uma conexão TCP.

Os servidores estão na mesma LAN que o HAProxy, portanto deve ser rápido. Aguarde pelo menos 5 segundos, porque é o tempo que leva para que algo inesperado aconteça (um pacote TCP perdido para retransmitir, um servidor bifurcando um novo processo para receber as novas solicitações, aumentar o 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 muito aumentado. (Nota: é provável que este seja um caso de arquitetura incorreta.)

verificação de tempo limite:

Defina o tempo limite da verificação adicional, mas somente após a conexão já estar estabelecida.

Definir tempo limite de verificação adicional, mas somente após a conexão já estar Se definida, o haproxy usa min ("timeout connect", "inter") como tempo limite de conexão para verificação e "timeout check" como tempo limite de leitura adicional. O "min" é usado para que as pessoas que executam com muito tempo "timeout connect" (por exemplo, aqueles que precisavam disso devido à fila ou tarpit) não reduzam a velocidade das verificações. (Observe também que não há motivos válidos para ter tempos limite de conexão tão longos, porque "fila de tempo limite" e "limite de tempo limite" sempre podem ser usados ​​para evitar isso).

Ler : Ao executar uma verificação de integridade, o servidor precisa timeout connectaceitar a conexão e timeout checkdar a resposta.

Todos os servidores devem ter uma verificação de saúde HTTP (S) configurada. Essa é a única maneira de o balanceador de carga saber se um servidor está disponível. A verificação de saúde é uma /isalivepágina simples , sempre respondendo OK.

Dê a esse tempo limite pelo menos 5 segundos, porque é o tempo que demora quando algo inesperado acontece (um pacote TCP perdido para retransmitir, um servidor bifurcando um novo processo para receber as novas solicitações, aumentar o tráfego).

História de Guerra : Muitas pessoas acreditam erroneamente que o servidor sempre pode responder a esta página simples em 3 ms. Eles definem um tempo limite agressivo (<2000ms) com failover agressivo (2 verificações com falha = servidor morto). Eu vi sites inteiros caindo por causa disso. Normalmente, há um ligeiro pico no tráfego, os servidores back-end ficam mais lentos, as verificações de saúde são adiadas ... até que de repente eles se esgotam, o HAProxy acha que TODOS os servidores morreram de uma só vez e todo o site foi desativado.