我正在尝试配置 HAProxy 来为我创建的自定义 Web 服务器进行负载平衡。现在我注意到，随着返回消息的大小增加，HAProxy 的延迟越来越大。例如，我运行了四个不同的测试，结果如下：
通过 HAProxy 响应 15kb：
平均响应时间：.34 秒
交易率：763 笔交易/秒
吞吐量：11.08 MB/秒
通过 HAProxy 响应 2kb：
平均响应时间：.08 秒
交易率：1171 笔交易/秒
吞吐量：2.51 MB/秒
直接向服务器响应 15kb：
平均响应时间：.11 秒
交易率：1046 笔/秒
吞吐量：15.20 MB/秒
直接向服务器响应2kb：
平均响应时间：.05 秒
交易率：1158 笔交易/秒
吞吐量：2.48 MB/秒
所有事务都是 HTTP 请求。如您所见，响应较大时，响应时间之间的差异似乎比响应较小时大得多。我知道使用 HAProxy 时会有轻微的延迟。不确定这是否重要，但测试本身是使用 siege 运行的。并且在测试期间，HAProxy 后面只有一台服务器（与直接到服务器测试中使用的服务器相同）。这是我的 haproxy.config 文件：
global
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
maxconn 10000
user haproxy
group haproxy
daemon
#debug
defaults
log global
mode http
option httplog
option dontlognull
retries 3
option redispatch
option httpclose
maxconn 10000
contimeout 10000
clitimeout 50000
srvtimeout 50000
balance roundrobin
stats enable
stats uri /stats
listen lb1 10.1.10.26:80
maxconn 10000
server app1 10.1.10.200:8080 maxconn 5000
我在这个文件中找不到太多可以帮助我解决问题的选项。我听到有人建议我可能需要调整一些 sysctl 设置。但是，我找不到很多关于此的信息，大多数文档都是针对 Linux 2.4 和 2.6 的 sysctl 内容，我正在运行 3.2（Ubuntu 服务器 12.04），它似乎是自动调整的，所以我不知道我应该或不应该更改什么。我尝试的大多数设置更改对性能没有影响或有负面影响。
请注意，这是一个非常初步的测试，我希望在部署时，我的 HAProxy 将能够平衡到许多服务器的 10k-20k 请求/秒，因此如果有人可以提供信息来帮助我实现该目标，我将不胜感激。
非常感谢您提供的任何信息。如果您需要我提供更多信息，请告诉我，我会尽我所能为您提供。
[编辑] 根据要求 haproxy -vv
HA-Proxy version 1.4.18 2011/09/16
Copyright 2000-2011 Willy Tarreau <[email protected]>
Build options :
TARGET = linux26
CPU = generic
CC = gcc
CFLAGS = -O2 -g -fno-strict-aliasing
OPTIONS = USE_LINUX_SPLICE=1 USE_LINUX_TPROXY=1 USE_PCRE=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200
Encrypted password support via crypt(3): yes
Available polling systems :
sepoll : pref=400, test result OK
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 4 (4 usable), will use sepoll.
答案1
我正在考虑几点：
1）您是否在虚拟化环境中运行？
2）您的机器上是否加载了 nf_conntrack？
3)您是否在任何时候使任何一台涉及的机器的 CPU 饱和？
4）请使用“option http-server-close”而不是“option httpclose”，因为后者会让双方自行关闭，从而导致连接更长。
5) 您在 haproxy 的日志中看到了什么？时间将分为多个字段，让您分析时间花在了哪里。
6）如果您在 haproxy 的日志中看到的时间比在测试机器上看到的时间小得多，则意味着延迟是由 SYN 数据包在系统积压中等待（或更糟的是，重新传输）引起的，这可能是由于系统调整不足造成的。
7)（不太重要），当报告旧版本的问题时，您应该先将其更新到最新修复程序（1.4.22）以查看问题是否仍然存在。我认为您观察到的问题与任何已知问题都不相符，但这仍然是一般的想法。