Estou investigando a substituição de um balanceador de carga de software proprietário por HAProxy. Como parte dessa investigação, estou tentando testar o HAProxy sob carga. Embora minha configuração HAProxy funcione bem ao testá-lo como um único usuário, assim que coloco qualquer carga nele, a velocidade do site começa a cair drasticamente, e em pouco tempo (~ 100 usuários simulados) nossa ferramenta de teste de carga começa a relatar falhas.
É uma configuração bastante direta, com apenas pontos notáveis sendo que estamos usando o HAProxy 1.5.4 com suporte a OpenSSL e PCRE compilado e usado. Também temos algumas ACLs para corresponder em URLs, embora esse frontend não esteja sendo usado neste teste de carga.
Isso está sendo executado em uma máquina do CentOS 6.5.
Nossa configuração (sanitizada) para a combinação frontend / backend no teste de carga, junto com global e padrões:
global
daemon
tune.ssl.default-dh-param 2048
maxconn 100000
maxsessrate 100000
log /dev/log local6
defaults
mode http
option forwardfor
option http-server-close
timeout client 61s
timeout server 61s
timeout connect 13s
log global
option httplog
frontend stats
bind xxx.xxx.xxx.xxx:80
default_backend stats-backend
backend stats-backend
stats enable
server stats 127.0.0.1:80
frontend portal-frontend
bind xxx.xxx.xxx.xxx:80
default_backend portal-backend
frontend portal-frontend-https
bind xxx.xxx.xxx.xxx:443 ssl crt /path/to/pem
default_backend portal-backend
backend portal-backend
redirect scheme https if !{ ssl_fc }
appsession session len 140 timeout 4h request-learn
server web1.example.com web1.example.com:80 check
server web2.example.com web2.example.com:80 check
[...snip...]
Durante o teste de carga, estamos obtendo algumas informações dos logs, mas não grandes quantidades. Snippets relevantes:
Sep 4 11:06:12 xxxx haproxy[15609]: xxx.xxx.xxx.xxx:30983 [04/Sep/2014:11:05:42.984] portal-frontend-https~ portal-frontend-https/<NOSRV> -1/-1/-1/-1/28782 408 212 - - cR-- 1840/1840/0/0/0 0/0 "<BADREQ>"
...
Sep 4 11:06:03 xxxx haproxy[15609]: xxx.xxx.xxx.xxx:61502 [04/Sep/2014:11:05:47.810] portal-frontend-https~ portal-frontend-https/<NOSRV> -1/-1/-1/-1/14345 400 187 - - CR-- 1715/1693/0/0/0 0/0 "<BADREQ>"
...
Sep 4 11:06:03 xxxx haproxy[15609]: xxx.xxx.xxx.xxx:43939 [04/Sep/2014:11:05:59.553] portal-frontend portal-backend/<NOSRV> 314/-1/-1/-1/2602 302 181 - - LR-- 1719/22/223/0/3 0/0 "GET /mon/login.php?C=1&LID=15576783&TID=8145&PID=8802 HTTP/1.1"
Com base nessas entradas de log, tentamos coisas como ajustar a solicitação HTTP de tempo limite, mas sem nenhuma melhoria (o teste de carga será executado por mais tempo antes que as falhas sejam relatadas por nossa ferramenta, mas a redução ocorrerá em um maneira similar).
Estou confiante que o HAProxy é capaz de fazer muito melhor do que isso, mas eu realmente não sei para onde ir agora para começar a diagnosticar qual é o problema (ou limitação).Por favor, execute o dmesg e assegure-se de que a tabela conntrack do iptables não esteja cheia ... Você pode ter muitas mensagens como esta: "ip_conntrack: table full, dropping packet"
Se sim, ajuste seu sysctl: net.ipv4.netfilter.ip_conntrack_max O valor padrão é muito baixo. Você pode configurá-lo para 50000, talvez mais, depende da sua carga de trabalho.
Baptiste
Felix está certo. Você precisa do maxconn em seus servidores back-end em um nível baixo e seu maxconn global é muito alto. Coloque isso em algo como 4000.
É fundamental que você entenda a diferença no global e no servidor maxconn.
Willy Tarreau (autor de HAProxy) descreve muito claramente aqui: link
Estou usando o HAProxy há anos e meu padrão é 64 maxcon nos servidores back-end.
O HAProxy tem um desempenho muito alto e é certamente capaz de sobrecarregar um servidor da web se estiver configurado incorretamente. Dê uma olhada nas conexões de rede e nos logs de erro dos servidores da Web para ver se eles atingem as conexões máximas. Eu não ficaria surpreso se fosse esse o caso.