Question

我们在Amazon EC2上设置了haproxy（v 1.5.1），它正在完成两项工作

根据请求的子域路由路由流量
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

Answer 1

我的第一个想法就是这个，来自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 ...

这两个请求来自相同的IP地址和相同的源端口 - 因此，这是来自同一客户端连接的两个请求，在时间上分开~17秒（我允许Keepalives）比此特定代理群集上的默认值更长。）

Tq计时器（上面的值是2022毫秒和17091毫秒）是“获取客户端请求的总时间” - 在任何给定客户端的初始请求中，此计时器在该行停止时解码后的标题末尾的中断。但是，在后续请求中，该计时器还包括在结束之后经过的空闲时间或在下一个请求到达之前的先前请求。（如果我再往前走，我会发现来自同一个IP /端口对的更多请求，直到我到达第一个，其实际上有Tq为0，但情况并非总是如此。）

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

使用option http-server-close允许客户端连接保持打开状态，同时在每次请求后关闭服务器连接，从而为您提供保持与客户端的活动连接的优势，从而优化（通常）更长时间链中的路径（就延迟而言），而不是使用空闲连接来捆绑后端服务器资源。

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

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

1 个答案: