我们如何使用HAProxy实现单机200万SSL连接(3)

如果将 CPU 核数从 8 个增加到 16 个,我们发现每秒的请求数量并没有大幅度增加.如果在生产环境中使用 8 核机器,那么我们不会分配所有的核给 HAProxy,或者是它的任何其他进程. 所以我们决定用 6 核机器进行一些测试,看看是否能得到可接受的数字.

结果还不错.

引入 sleep

我们现在对负载测试结果非常满意. 然而,这并没有模拟真正的生产场景. 当我们引入 sleep,才开始模拟生产环境的情况.

echo “POST https://test.haproxy.in:443/ping” | vegeta -cpus=32 attack -duration=10m ?-header=”sleep:1000″ ?-body=post_smaller.txt-rate=2000 -workers=500 ?| tee reports.bin | vegeta report

因此,x 毫秒的随机 sleep 时间将导致服务器 sleep 时间为 0 < x < 1000 . 因此上述负载测试将给出平均?≥ 500ms 的延迟.

最后一个单元格中的含义是 TCP established,Packets Rec,Packets Sent

从表中可以看到,6 核机器可以支持的最大请求量从 20k 减少到 8k. 显然,sleep 有其影响,影响的是 TCP 连接的数量. 然而这距离我们设定的 700K 目标还很远.

里程碑 #1

我们如何增加 TCP 连接的数量? 很简单,不断增大 sleep 时间,连接数应该上升. 我们一直增加 sleep 时间并在 60 秒的 sleep 时间停了下来. 这意味着大约 30 秒的平均延迟.

Vegeta 可以提供成功请求百分比的结果参数. 我们看到,在上述的 sleep 时间,只有 50％ 的调用是成功的. 请看下面的结果.

我们达到了 400 万个 TCP 连接,在每秒 8k 请求和 60s 的 sleep 时间的情况下. 60000R 的 R 表示随机.

我们的第一个的发现是,在 Vegeta 中有一个默认的超时时间是 30 秒,这就解释了为什么 50％ 的请求会失败. 所以我们在后续测试中将超时调整到 70 秒,并随着需求的变化而不断变化.

在客户端调整超时值之后,我们可以轻松地达到 700k 标准. 唯一的问题是这些不可持续,只是峰值的数据. 系统达到了 600k 或 700k 的峰值链接,但并没有坚持很长时间.

但是我们想要得到图上连接持续很久的效果

这显示了稳定保持 780k 连接的状态.如果仔细查看上面的统计信息,每秒的请求数量非常多.然而,在生产环境中,我们在单个 ?HAProxy 机器上的请求数量要少得多(约 300 个).

我们确信,如果减少生产环境的 HAProxy 的数量(约 30 个,这意味着每秒 30 * 300?9k 的连接),我们将会达到机器 TCP 连接限制,而不是 CPU.

所以我们决定实现每秒 900 个请求、30MB/s 的网络流量,以及 210 万 TCP 连接.我们选用这些数字,因为这将是单个生产环境 HAProxy 机器的 3 倍流量.

到目前为止,我们已经配置了 HAProxy 使用 6 核.我们只想测试 3 核,因为这是我们在我们的生产机器上使用的最简单的方法(如前所述,我们的生产机器是 4 核 30G,所以用 nbproc = 3 进行更改将是最简单的).

里程碑 #2

现在我们对每秒请求的最大限制可以随机器不同而变化,所以我们只剩下一个任务,如上所述,实现 3 倍的生产负载：

• 每秒 900 个请求
• 建立了 210 万个 TCP 链接.
• 30 MB/s 网络.

在 220k 的测试环境下,我们再次陷入僵局. 无论客户机数量多少或睡眠时间多少,TCP 连接数似乎都停留在那里.

我们来看一些估算数据. 220k TCP 连接,每秒 900 个请求 = 110,000 / 900?= 120 秒.达到了 110k,因为 220k 连接包括上行和下行.

当我们在 HAProxy 开启日志时,我们怀疑 2 分钟是系统某处的限制. 我们可以看到 120,000 ms 是日志中大量连接的总时间.

在进一步调查中,我们发现 NodeJs 的默认请求超时为 2 分钟. 瞧!

但我们的高兴显然很短暂,在 130 万,HAProxy 连接数突然下降到 0,并再次开始增长.我们很快检查了 dmesg 命令,里面可以查到 HAProxy 进程一些有用的内核信息.

基本上,HAProxy 进程已经耗尽内存.因此,我们决定增加机器内存,并将其转移到 nbproc = 3 的 16 核 64GB 的机器,经过调整,我们终于可以达到 240 万长连.

后端代码

下面是正在使用的后端服务器代码. 我们还在服务器代码中使用 statsd 来获取客户端接收的每秒请求的统计数据.

我们还有一个小脚本运行多个服务器. 我们有 8 台机器,每台机器部署了 10 个后端服务. 我们真的认为有条件的话可以进行无限扩容进行压测.

（编辑：ASP站长网）