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

最初,当我们开始测试 HAProxy 时,发现使用 SSL 情况下,CPU 很早就到了瓶颈,而每秒请求数都很低. 在使用 top 命令后,发现 HAProxy 只使用 1 个 CPU 核. 而我们还有 15 个以上的核没用.
Google 了 10 分钟后,我们在 HAProxy 中找到某个设置,可以让 HAProxy 使用多个核.

它被称为 nbproc,具体设置请看这篇文章 [8]：
调整此设置是我们的负载测试策略的基础. ?让我们可以方面的进行 HAProxy 组合以便测试.

使用 AB 进行压力测试

当开始负载测试之旅时,我们不清楚应该测量的指标和需要达到的目标.

最初,我们只有一个目标：通过改变所有下面提到的参数来找到临界点.

我保留了各种负载测试结果的表格. 总而言之,做了 500 多次测试,以达到最终的效果. 您可以清楚地看到,每次测试都有很多不同的部分.

单客户端问题

我们看到客户端正在成为瓶颈,因为我们不断增加每秒的请求数. ab 使用单个核,从文档中可以看出,它不提供使用多核的功能.
为了有效地运行多个客户端,我们发现一个有用的 Linux 工具叫做 Parallel [7]. 顾名思义,它可以帮助您同时运行多个命令来达到并行的目的. 正是我们想要的.
看一下使用 Parallel 运行多个客户端的示例命令.

上述命令将运行 3 个 ab 客户端击访问同一个 URL. 这有助于我们消除客户端瓶颈.

Sleep 及 Times 参数的问题

下面是 Ganglia 中的一些参数.让我们简单讨论一下.

1. packets sent and received?为了产生更多数据,可以在 post 请求中添加更多数据
2. tcp_established 这是想实现的目标.想象一下,如果单个 ping 请求大约需要一秒钟,那么每秒需要大约 700k 个请求来达到 tcp_established 的目标.现在这个数字在生产环境中可能看起来更容易达到,但是在测试场景中不太可能达到.

我们在 POST 调用中加入了一个 sleep 参数,它指定了服务端发送返回之前需要 sleep 的毫秒数.这将模拟长时间运行的生产环境请求.如果让请求 sleep 20 分钟的话,只需要每秒发出 583 个请求就能达到 700k 并发连接的标准.

此外,我们还在 POST 调用中引入了另一个参数： times.服务器在返回请求时应该在 TCP 连接上写入响应的指定次数,这有助于模拟更多的数据.

Apache Bench (AB) 的问题

虽然使用 AB 也得到了不少测试结果,但同时也遇到了很多问题.我不会在这里提到所有问题,因为不是这篇文章重点(下面介绍另一个客户端).

我们非常满意从 ab 上获得的结果,但是它不支持在一段时间内生成所需指定的 TCP 连接数.不知何故,我们设置的 sleep 参数在 ab 上无法生效.

虽然在一台机器上可以运行多个 ab 客户端并且可以用工具合并结果,但是在多台客户机上运行此设置对我们来说仍然是一件痛苦的事情.那时我还没有听说过 pdsh [4] 这个工具.

此外,我们也没有关注过超时的问题.在 HAProxy,ab 客户端和服务器上有一些默认的超时设置,我们完全忽略了这些.后文会讲到.

我们一开始就提到通过临界点图来检测系统的上限,但讲了这么多有点偏离了最主要目标.然而,要得到有意义的结果只能着眼于这一点.

使用 AB 碰到的一个问题是到了某个点 TCP 连接数不再增加.我们有大约 40 – 45 个客户端运行在 5 – 6 台客户端机上,但依然不能达到想要的规模.理论上,TCP 连接的数量应该随着 sleep 时间的增加而增加,但对我们来说并非如此.

引入 Vegeta

因此我们需要寻找一个负载测试工具,这些工具需要具有更好的扩展性和更好的功能性,最终,我们找到了 Vegeta [6].
从我的个人经验来看,我已经看到 Vegeta 具有极高的扩展性,与 ab 相比,它提供了更好的功能. 在我们的负载测试中,单个 Vegeta 客户端能够产生相当于 15 倍 ab 的吞吐量.

下面,我将提供使用 Vegeta 的负载测试结果.

使用 Vegeta 进行负载测试

首先,看看我们用来运行一个 Vegeta 客户端的命令. 进行测试的命令称为 attack：(酷吧?)

我们太喜欢 Vegeta 提供的参数了,来看看下面的一些参数.

• -cpus = 32 指定此客户机要使用的 CPU 核数. 由于要生成的负载量,我们不得不将客户机扩展到 32 核 64G. 虽然上面的速度也不是特别高. 但是当有大量处于 sleep 状态的连接时,维持这些连接也会产生比较大的开销.
• -duration = 10m 我想这是不言自明的.如果没有指定任何持续时间,测试将永远运行.
• -rate = 2000 每秒请求的数量.

所以如上图所示,我们在一台 4 核机器上每秒达到了 32k 请求量. 如果你记得临界点图,在这种情况下,非 SSL 请求的临时点是 31.5k.
从负载测试中看更多的结果.

16k 的 SSL 连接也不错. 请注意,在我们的负载测试过程中,必须从头开始,因为我们采用了一个新的客户端,它给了我们比 ab 更好的结果. 所以不得不再来一遍.

CPU 核数的增加导致机器在未达到 CPU 限制前,每秒可以用的请求数增加.

（编辑：辽源站长网）

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