Назад | Перейти на главную страницу

понимание статистики текущей сессии HAProxy Frontend и Backend

Я настроил HAProxy с одним интерфейсом и сервером, на странице статистики я вижу следующую статистику:

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%

На Frontend в разделе Sessions я вижу:

Cur: 360
Max: 427
Limit 2000

На серверной части:

Cur: 0
Max: 3
Limit: 2000

Для упрощения прикрепляю изображение с этими цифрами:

Я не совсем понимаю, почему, если текущие соединения: 361, в Backend есть 0.

Может быть так, что HAproxy ограничивает / ставит в очередь входящее соединение, чтобы каким-то образом защитить бэкэнд (ы) из-за timeout queue установка?

Как узнать, сколько времени требуется клиентскому интерфейсу для связи с сервером?

Это тестовая конфигурация, которую я использую:

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

Заранее спасибо.

Вы используете option http-server-close.

SCL: закрытие сервера ("option http-server-close"): соединение с сервером закрывается после получения ответа, но соединение с клиентом остается открытым.

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

Внешние соединения - это соединения браузера, которые уже отправили запрос и получили ответ и теперь поддерживаются прокси-сервером, который следит за тем, чтобы браузеры отправили свой следующий запрос, после чего новое соединение с серверная часть будет создана для обслуживания запроса. Или (что менее вероятно) это клиенты, которые подключились, но еще не отправили запрос. Они будут закрыты, когда timeout http-keep-alive или timeout http-request срабатывает без поступления полного нового запроса.

timeout queue здесь не фактор. Этот таймер определяет, как долго запросы будут приостановлены - поставлены в очередь - ожидают открытия maxconn слот, когда сервер, серверная часть или интерфейсная часть имеют maxconn активные соединения. Этот таймер срабатывает и выдает ошибку браузеру, когда запрос находится в очереди и ожидает слот в течение настроенного количества времени ... но таймер не запускается, если запрос фактически не поставлен в очередь - а запросы не в очереди, кроме "maxconn-connections-active-now ». Согласно этой статистике, этого никогда не происходит в вашей среде, потому что объем запросов никогда не был достаточным для того, чтобы запросы вообще помещались в очередь.

Время для установления соединения с сервером находится в Tc параметр в журнал http.