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

如果将 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

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!