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

通过 Ganglia 可以监测 HAProxy 机器上一些重要参数.

1. TCP ?established 这告诉我们在系统上建立的 TCP 连接总数.注意：这是上行和下行连接的总和.
2. packets sent and received 发送和接收的 TCP 数据包的总数.
3. bytes sent and received 这将显示发送和接收的字节数.
4. memory 随着时间的推移使用的内存数.
5. network?通过线路发送数据包而消耗的网络带宽.

以下是通过通过负载测试找到的已知限制.

700k TCP 连接,

50k 发送包数量,60k 接收包数量,

10-15MB 发送及接收的字节数,

14-15G 内存峰值,

7MB 带宽.

所有这些值都是基于每秒数据

HAProxy Nbproc

最初,当我们开始测试 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 限制前,每秒可以用的请求数增加.

（编辑：ASP站长网）