Home / server / Questions / 777088
Accepted
nbari
Asked: 2016-05-17 07:59:12 +0800 CST

understanding HAProxy Frontend and Backend current session stats

  • 772

I have configured HAProxy with a single Frontend and Backend, from the stats page I see the following stats:

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%

On the Frontend on the Sessions section I see:

Cur: 360
Max: 427
Limit 2000

An on the Backend:

Cur: 0
Max: 3
Limit: 2000

To simplify I attach the image with this numbers: enter image description here

The thing that I don't properly understand, is why if the current connections are: 361, the Backend has 0.

Could it be that HAproxy limit/queue the incoming connection to some how protect the backend(s), due the timeout queue setting?

How to know the time it takes the Frontend to contact the Backend?

This is the test configuration I am using:

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

Thanks in advance.

haproxy

1 Answers

  1. Best Answer

    You're using 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

    The front-end connections are browser connections that have already sent a request, and received a response, and are now being kept alive by the proxy, which is watching for the browsers to send their next request, at which point, a new connection to the back-end will be established to service the request. Or (less likely) they are clients that have connected but not sent a request yet. They'll be closed when timeout http-keep-alive or timeout http-request fires without a complete new request arriving.

    timeout queue is not a factor, here. This timer specifies how long requests will be suspended -- queued -- waiting for an open maxconn slot when the server, back-end, or front-end has maxconn active connections. This timer fires off and throws an error to the browser when a request has been queued and waiting for a slot for the configured amount of time... but the timer doesn't start unless a request is actually queued -- and requests are not queued except in a "maxconn-connections-active-now" condition. According to these stats, this is never happening in your environment because the request volume has never been sufficient to cause requests to be queued at all.

    The time for the backend connection to be established is found in the Tc parameter in the http log.

    • 6