compreendendo as estatísticas da sessão atual do HAProxy Frontend e do Backend

Question

Eu configurei o HAProxy com um único Frontend e Backend, na página de estatísticas eu vejo as seguintes estatísticas:

system limits: memmax = unlimited; ulimit-n = 20013
maxsocs = 20013; maxconn = 10000; maxpripes =0
current conns = 361; current pipes 0/0; conn rate = 27/sec
Running tasks: 1/366; idle = 98%

Na seção Frontend on the Sessions, vejo:

Cur: 360
Max: 427
Limit 2000

Um no back-end:

Cur: 0
Max: 3
Limit: 2000

Para simplificar, anexei a imagem com esses números:

O que não entendo corretamente é por que, se as conexões atuais são: 361 , o Backend tem 0 .

Pode ser que o limite de maiopróxi limita / enfileira a conexão de entrada para alguns como proteger o (s) servidor (es), devido à configuração timeout queue ?

Como saber o tempo que o Frontend leva para entrar em contato com o Backend?

Esta é a configuração de teste que estou usando:

global
    maxconn 10000
    spread-checks 3
    log /var/run/log local0 notice
    daemon
    tune.ssl.default-dh-param 2048
    ssl-default-bind-options no-sslv3 no-tls-tickets
    ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:HIGH:!aNULL:!MD5:!DSS
    ssl-default-server-options no-sslv3
    ssl-default-server-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:HIGH:!aNULL:!MD5:!DSS
defaults
    balance roundrobin
    option http-server-close
    option abortonclose
    option dontlognull
    mode http
    timeout check           3s
    timeout client          30s  # Client and server timeout must match the longest
    timeout connect         5s
    timeout http-keep-alive 10s
    timeout http-request    10s  # A complete request may never take that long.
    timeout queue           10s  # Don't queue requests too long if saturated.
    timeout server          10s  # Time we may wait for a response from the server.
    retries 3
    log global
    errorfile 408 /dev/null
frontend http-in
    bind *:80
    option httplog
    option forwardfor if-none
    default_backend nodes-http
backend nodes-http
    option httpchk GET /
    http-check disable-on-404
    rspirep ^Cache-Control Cache-Control:\ public,\ max-age=60,\ must-revalidate
    server node1 :8000 maxconn 2000 check

Obrigado antecipadamente.

    

Answer 1

Você está usando option http-server-close .

SCL: server close ("option http-server-close") : the server-facing connection is closed after the end of the response is received, but the client-facing connection remains open.

http://cbonte.github.io/haproxy-dconv/configuration-1.6.html#4

As conexões front-end são conexões de navegador que já enviaram uma solicitação, receberam uma resposta e agora estão sendo mantidas vivas pelo proxy, que está aguardando que os navegadores enviem sua próxima solicitação, ponto no qual, Uma nova conexão com o back-end será estabelecida para atender a solicitação. Ou (menos provável) são clientes que se conectaram, mas ainda não enviaram uma solicitação. Eles serão fechados quando timeout http-keep-alive ou timeout http-request disparar sem a chegada de uma nova solicitação completa.

timeout queue não é um fator aqui. Esse cronômetro especifica por quanto tempo as solicitações serão suspensas - enfileiradas - aguardando um intervalo maxconn aberto quando o servidor, o back-end ou o front-end tiver maxconn de conexões ativas. Esse timer dispara e lança um erro para o navegador quando uma solicitação foi enfileirada e aguardando um slot pelo período de tempo configurado ... mas o cronômetro não é iniciado a menos que uma solicitação seja realmente enfileirada - e as solicitações não são na fila, exceto em uma condição " maxconn -connections-active-now". De acordo com essas estatísticas, isso nunca está acontecendo em seu ambiente porque o volume de solicitações nunca foi suficiente para fazer com que as solicitações sejam enfileiradas.

O tempo para a conexão de back-end ser estabelecida é encontrado no parâmetro Tc no link .