Depende do protocolo e do caso de uso para equilibrar. Para qualquer coisa em que a quantidade de conexões esteja correlacionada com a carga / uso, é melhor usar leastconn
. Devido à maneira como as redes e os aplicativos funcionam, é quase sempre verdade e é melhor usar leastconn
por padrão.
Áreas de trabalho remotas RDP / X11 / Jump Hosts
Por exemplo, uma empresa possui um pool de áreas de trabalho remotas às quais os funcionários se conectam. Você gostaria que os funcionários fossem distribuídos de maneira uniforme pelos desktops.
O número de conexões ativas nesse caso de uso é aproximadamente "quantos funcionários estão usando essa área de trabalho no momento". O host com menos conexões possui menos funcionários e é provavelmente o menos carregado. Use "leastconn" nessas circunstâncias, ele distribui a carga uniformemente com a quantidade de usuários.
Um balanceador de carga ideal deve estar ciente da carga da área de trabalho remota. Quantos usuários? Quantas aplicações? Quanta memória e CPU consumiram? Existem soluções comerciais dedicadas a desktops remotos (Microsoft / Citrix / etc ...), que geralmente medem essas métricas para espalhar o uso muito bem. O HAProxy é um balanceador de carga de rede simples e não pode fazer melhor do que contar conexões com leastconn
.
HTTP / HTTPS
Com o HTTP, uma conexão ativa significa que o servidor está ocupado processando uma solicitação. As conexões são diretamente proporcionais à carga. Você deseja selecionar o servidor com a menor quantidade de conexões ativas (solicitações em andamento). Use leastconn
para tráfego HTTP (S).
Imagine um cenário com dois servidores HTTP, em que um servidor é mais lento para processar solicitações (talvez esteja sobrecarregado, talvez tenha hardware mais antigo).
roundrobin
distribuirá solicitações pela metade entre os dois servidores. É muito ineficiente, o servidor mais rápido deve demorar mais. Pior ainda, o servidor mais lento pode estar sobrecarregado, fica ainda mais lento à medida que mais solicitações chegam e pode começar a descartá-las a qualquer momento. Você não quer isso.
leastconn
detectaria que os servidores são desiguais. O servidor mais lento mantém as conexões por mais tempo, possui uma contagem maior de conexões. leastconn
é responsável por isso e prefere o outro servidor.
Na minha experiência, incluindo funções em que eu estava realizando testes de desempenho exclusivamente para sites moderados a grandes. leastconn
pode ser 300% mais eficiente que o roundrobin
HTTP (S). roundrobin
não distribui a conexão de maneira justa e causa instabilidade em alta carga.
Solicitação de DNS
(Vamos ignorar que o HAProxy não suporta UDP e UDP é menos conexão).
Um último exemplo. DNS é um protocolo simples. Os clientes enviam uma única mensagem UDP para solicitar um domínio e o servidor DNS responde em uma única mensagem.
Nesse caso, não há realmente uma conexão. Mesmo que houvesse, seria instantaneamente fechado (teoricamente).
Não faria sentido contar conexões nessas circunstâncias, não é o ideal leastconn
. Um simples roundrobin
pode distribuir mensagens.
Um mal-entendido comum
Às vezes, as pessoas acreditam que não devem usar leastconn
para conexões de vida curta (semelhante ao último exemplo). Até a documentação do HAProxy é enganosa sobre isso.
leastconn
Use of this algorithm is recommended where very long sessions are
expected, such as LDAP, SQL, TSE, etc... but is not very well
suited for protocols using short sessions such as HTTP.
[misleading advice, should ignore it]
No mundo real, short connections
não é uma coisa.
Os aplicativos são criados sobre o TCP. As mensagens são entregues e frequentemente processadas em ordem. Quando um servidor está lento ou sobrecarregado, as conexões "curtas" ficam mais longas. Se houver (mais) conexões, provavelmente há algum (mais) trabalho sendo realizado. A contagem e a duração da conexão variam e têm significado.
Pense em um servidor HTTP básico. Alguns ativos demoram alguns milissegundos, algumas chamadas de API demoram alguns segundos, uma página pode demorar a carregar com qualquer quantidade de solicitações, etc. As solicitações não têm vida curta, sua vida útil segue o que está sendo processado em qual servidor. leastconn
entende a atividade em andamento e ajusta a distribuição, que é exatamente o que você deseja de um balanceador de carga.