Não é possível ultrapassar ~ 11K solicitações por segundo com o Haproxy no modo http

2

Não estou conseguindo obter mais de 11 mil solicitações por segundo por instância haproxy.

Eu tenho duas instâncias haproxy no amazon EC2. Ambos sob uma instância c4.xlarge. Tentei configurar o parâmetro maxconn, o mapeamento da cpu e o limite do Linux sem qualquer sorte.

Estou usando o jmeter para fazer os testes e se eu executar dois jmetros paralelos configurados para atacar um dos haproxy cada eu mannage para obter cerca de 22K, mas se eu executar a mesma configuração mas ambos atacando apenas 1 instância haproxy o máximo a taxa de transferência é de 11 K.

Minha configuração haproxy é:

global
    nbproc 4
    cpu-map 1 0
    cpu-map 2 1
    cpu-map 3 2
    cpu-map 4 3
    maxconn 150000
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

    # Default SSL material locations
    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private

    # Default ciphers to use on SSL-enabled listening sockets.
    # For more information, see ciphers(1SSL). This list is from:
    #  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
    # An alternative list with additional directives can be obtained from
    #  https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy
    ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
    ssl-default-bind-options no-sslv3

defaults
    log global
    mode    http
    option  httplog
    option  dontlognull
    option      http-server-close
    retries     2
    timeout     http-request    10s
    timeout     queue           1m
    timeout     connect         5s
    timeout     client          1m
    timeout     server          1m
    timeout     http-keep-alive 20s
    timeout     check           15s
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http



frontend DSP_FRONT
    bind *:80
    maxconn 300000
    default_backend DSP_BACK

backend DSP_BACK
    balance hdr(device)
    mode http
    server dsp1 172.31.3.141:80 check
    server dsp2 172.31.8.195:80 check
    server dsp3 172.31.8.186:80 check


listen stats 
    bind :9000
    mode http
    stats enable
    stats hide-version
    stats realm HAproxy-Statistics
    stats uri /haproxy_stats

O backend deve ser muito rápido e o tamanho da resposta é bem pequeno (0.5-1kb).

Também tentei mexer nos limites do sistema.

fs.file-max = 10000000 
fs.nr_open = 10000000
net.ipv4.tcp_mem = 786432 1697152 1945728
net.ipv4.tcp_rmem = 4096 4096 16777216
net.ipv4.tcp_wmem = 4096 4096 16777216
net.ipv4.ip_local_port_range = 1000 65535

E também adicionou o limite de arquivos ao serviço haproxy systemd

LimitNOFILE = 300000

Mas parece não haver mudança.

Estou executando o haproxy no Ubuntu 16.04

L.E:

Saída de cat / proc / [haproxyprocid] / limits

ubuntu@ip-172-31-1-115:~$ ps ax| grep ha
 1214 ?        Ss     0:00 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
 1217 ?        S      0:00 /usr/sbin/haproxy-master
 1218 ?        Ss     0:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
 1219 ?        Ss     0:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
 1220 ?        Ss     0:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
 1221 ?        Ss     0:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
 1393 pts/0    S+     0:00 grep --color=auto ha
ubuntu@ip-172-31-1-115:~$ cat /proc/1217/limits 
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             29852                29852                processes 
Max open files            300035               300035               files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       29852                29852                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us  
    
por Sinjuice 08.06.2017 / 16:13

1 resposta

0

Você não menciona qual é o fator limitante. Primeiro você está executando em VMs compartilhadas, portanto, apenas o provedor de hospedagem sabe se eles oferecem uma CPU real ou não. Segundo, é possível que você esteja maximizando a CPU se estiver estressando o SSL. 11k req / s poderiam mais ou menos corresponder ao que esperar de conexões TLS retomadas em uma máquina moderada. Nesse caso, você verá 100% de CPU usada pelo haproxy, principalmente em userland (geralmente 60% usuário / 40% sys). Se você está fazendo 11k RSA2048, então parabéns por ele ser enorme! Se você está fazendo isso em conexões claras, é baixo, mas pode ser causado inteiramente pelo ambiente da VM. Se estiver em conexões keep-alive, é realmente muito baixo e pode até ser causado por latência de rede enorme (também comum com VMs extremamente reservadas em excesso).

    
por 09.06.2017 / 18:58