我已经使用单个前端和后端配置了 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%
在前端的“会话”部分我看到:
Cur: 360
Max: 427
Limit 2000
后端:
Cur: 0
Max: 3
Limit: 2000
我不太明白的是,为什么当前的连接是:361,后端有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
提前致谢。
答案1
您正在使用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 日志。