4

Apache Bench遇到的问题

虽然通过Apache Bench我们获取了很多结果数据，但同时也遇到了很多问题。这里不会说明所有遇到的问题，因为这不是本文的终点，而且后面将会介绍新的压测客户端。

我们对从Apache Bench获取到了不错的结果数据，但是每次获取一个点数据时，TCP连接数这个要求总是难以达到。不知道为何Apache Bench无法正确处理前面提到的sleep参数，同时也还是没法满足我们对容量的需求。

前面提到了我们在单台施压机上通过Parallel工具并行执行多个ab客户端，但这种方式无法跨多台施压机。当时还没有发现pdsh这个工具，也算是一个遗憾。

同时，之前的数据我们还缺少超时数据。在HAProxy上，我们会有一些默认的超时设置，但是ab客户端和后端服务完全忽略了这些配置。对此我们花了大量时间进行这方面的研究，试图修正压力测试的方案。

前面提到过拐点图，但是随着各种问题的出现，目标有所偏移。但是，为了获取有意义的结论，必须重新聚焦于此。

通过Apache Bench，我们获得了拐点，但是TCP连接数一直没有上升。这些数据基于5到6台施压机上运行的大约40到45个ab客户端获得，但是TCP连接数一直没能够达到期望的量级。理论上，随着sleep参数值的上升，TCP连接数应该会上升，但是事实上却没有效果。

引入Vegeta

基于使用Apache Bench所遇到的问题，我继续搜索其他功能更为强大、更易扩容的压力测试工具，最终找到了Vegeta。

从我个人经验来看，Vegeta相比于Apache Bench，非常易扩容，并且提供了更多的功能。在我们的压力测试场景中，一个Vegeta客户端可以产生相当于15个Apache Bench客户端的吞吐量。

下面会介绍使用Vegeta获取到的压力测试结果。

使用Vegeta进行压力测试

首先来看下单个Vegeta客户端的使用命令。有趣的是，其中用来向后端服务器施压的命令参数叫做attack :p

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

这里我们简单了解下Vegeta提供的一些参数细节：

-cpus=32，定义客户端使用的内核数量。为了能够达到需要的压力值，我们将施压机配置调整撑了32核64GB内存。仔细观察结果数据会发现，实际压力并不大，配置调整的主要目的是为了能够支撑大量状态为后端服务器休眠的连接。
-duration=10m，该参数顾名思义，如果没有指定执行时间，测试将永久运行。
-rate=2000，每秒钟请求数。

从上图可以看出，我们仅仅使用一台4核机器，就达到了每秒32k个请求。这个结果比之前得出的拐点图有更高的性能，这里针对非SSL请求的拐点在31.5k。

下面是更多压力测试的数据：

对于SSL连接来说，每秒请求数16k也不算差了。由于更换了新的客户端，整个压力测试过程都需要从头开始，但是从整体来看，结果都优于ab客户端的结果。

随着CPU内核数的增加，在相同压力下响应延迟都有所降低，直到压力达到CPU性能极限。

但是，我们发现当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

上述命令设置了1000毫秒的休眠时间，会让服务端应用随机休眠0到1000毫秒。因此上述命令的平均延迟是≥ 500ms。

最后一个单元格中的数字分别表示：

TCP连接建立数，包发送数，包接收数