HAProxy - 为什么要花时间让客户端请求非常高?

amd*_*lal 3 ssl amazon-ec2 haproxy

我们在Amazon EC2上设置了haproxy(v 1.5.1),它正在完成两项工作

  1. 根据请求的子域路由流量
  2. SSL终止

我们服务器上的ulimit是128074,并发连接是~3000.

我们的配置文件如下所示.我们面临的问题是haproxy日志中的时间Tq非常高(2-3秒).配置或我们遗漏的东西有什么问题吗?

global
    daemon
    maxconn 64000
    tune.ssl.default-dh-param 2048
    log 127.0.0.1 local0 debug

defaults
    mode http
    option abortonclose
    option forwardfor
    option http-server-close
    option httplog
    timeout connect 9s
    timeout client 60s
    timeout server 30s
    stats enable
    stats uri /stats
    stats realm Haproxy\ Statistics
    stats auth username:nopass

frontend www-http
    bind *:80

    maxconn 64000
    http-request set-header U-Request-Source %[src]
    reqadd X-Forwarded-Proto:\ http

    errorfile 503 /var/www/html/sorry.html

    acl host_A    hdr_dom(host) -f /etc/A.lst
    acl host_B    hdr_dom(host) -f /etc/B.lst
    use_backend www-A         if host_A
    use_backend www-B         if host_B
    log global

frontend www-https 
    bind *:443 ssl crt /etc/ssl/private/my.pem no-sslv3
    http-request set-header U-Request-Source %[src]
    maxconn 64000
    reqadd X-Forwarded-Proto:\ https

    errorfile 503 /var/www/html/sorry.html

    acl host_A        hdr_dom(host) -f /etc/A.lst
    acl host_B        hdr_dom(host) -f /etc/B.lst

    use_backend www-A if host_A
    use_backend www-B if host_B
    log global


backend www-A
    redirect scheme https if !{ ssl_fc }
    server app1 app1.a.mydomain.com:80 check port 80

backend www-B
    redirect scheme https if !{ ssl_fc }
    server app1 app1.b.mydomain.com:80 check port 80
Run Code Online (Sandbox Code Playgroud)

Mic*_*bot 7

我的第一个想法就是这个,来自HAProxy文档:

如果Tq接近3000,则客户端和代理之间可能丢失了数据包.这在本地网络上非常罕见,但可能在客户端位于远程远程网络并发送大量请求时发生.

......然而,当是通常只有真正Tq真的接近3000毫秒.我偶尔会在跨大陆连接的日志中看到这一点,但这种情况非常罕见.相反,我怀疑你所看到的是这样的:

设置option http-server-close可能会显示更长的请求时间,因为Tq还会测量等待其他请求所花费的时间.

这是更可能的解释.

您可以通过查找其中一个"可疑"日志条目,然后向上滚动以从同一源IP和端口查找上一个条目来确认这一点.

例子,来自我的日志:

Dec 28 20:29:00 localhost haproxy[28333]: x.x.x.x:45062 [28/Dec/2014:20:28:58.623] ...  2022/0/0/12/2034 200 18599 ... 

Dec 28 20:29:17 localhost haproxy[28333]: x.x.x.x:45062 [28/Dec/2014:20:29:00.657] ... 17091/0/0/45/17136 200 19599 ...
Run Code Online (Sandbox Code Playgroud)

这两个请求来自相同的IP地址和相同的源端口 - 因此,这是来自同一客户端连接的两个请求,在时间上分开~17秒(我允许keepalive长于此特定代理群集上的默认值) .

Tq计时器(以上,这些值是2022毫秒和17091毫秒)是"总时间,以获得客户机请求" -上从任何给定的客户端的初始请求,该定时器停止当在报头的末尾的换行符解码.但是,在后续请求中,该计时器还包括在结束之后经过的空闲时间或在下一个请求到达之前的先前请求.(如果我再往前走,我会发现来自同一个IP /端口对的更多请求,直到我到达第一个,实际上有一个Tq0,但情况并非总是这样.)

如果您可以在日志中回溯并查找来自相同客户端IP和端口的所有时间加起来的先前请求,那么您就是所看到的 - HAProxy正在计算在打开的,保持活动的连接上花费的时间,等待对于来自客户端的下一个请求...所以这种行为很正常,不应该引起关注.

使用option http-server-close允许客户端连接保持打开状态,同时在每次请求后关闭服务器连接,从而使您能够保持与客户端的活动连接,从而优化(通常)较长路径(就延迟而言)链,而不是通过空闲连接捆绑后端服务器资源.

http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#8.4