3

HAProxy Nbproc配置

刚开始对HAProxy进行压力测试的时候，我们发现增加了SSL之后CPU使用率一下子就飙升，但此时的每秒请求数却很低。通过top命令排查之后发现，HAProxy只使用了1个CPU内核，而我们的机器上还有15个空闲的内核。

通过Google发现HAProxy有一个设置可以使其充分利用多核。这个配置称为nbproc，详情及其具体配置可以参照这篇文章：

http://blog.onefellow.com/post/82478335338/haproxy-mapping-process-to-cpu-core-for-maximum

这项配置调优使得后面的压力测试能够继续，因为让HAProxy能够充分利用多核才能继续后续压力测试集中的各种混合场景。

使用AB进行压力测试

从这里开始正式进入压力测试环节，以后将不再赘述我们的度量数据和期望达到的指标。

刚开始我们的唯一目标是通过分析前面描述的ab命令参数变化，找到性能拐点。

上表是我们进行了多次压力测试之后的结果数据。为了获得这样的结果，我们进行了超过500次测试，从数据上可以明显看出，每次测试结果都有多项数据有变动。

单客户端问题

随着压力的逐渐增加，我们发现施压客户端成了瓶颈。从Apache bench文档来看，它在发起请求时只使用单核，并且没有设置可以利用多核提升其性能。

为了能够提升客户端性能，我们使用了Linux平台上的一个工具，叫做Parallel。如果其名称一样，该工具能够并行命令，以充分利用CPU核心。这也是我们所期望的。以下是使用Parallel运行多个ab客户端的示例命令：

cat hosts.txt |  parallel  'ab  -S -p post_smaller.txt -T
 application/json -n 100000 -c 3000 {}'
sachinm@ip-192-168-0-124:~$ cat hosts.txt
http://test.haproxy.in:80/ping
http://test.haproxy.in:80/ping
http://test.haproxy.in:80/ping

上述命令可以并行运行3个ab客户端，同时访问相同的URL。这样能够帮我我们解决客户端性能瓶颈。

服务端的Sleep和Times参数

前面我们提到了一些通过Ganglia收集的数据，这里先来讨论下如何模拟这些数据的产生。

发送和接收数据包数量。该数据可以通过POST请求中发送一些数据来模拟。该方式也能帮助提升带宽和收发字节数两项Ganglia数据项。
TCP连接建立数。为了模拟该数据，着实让我们花了好多时间。试想如果一个请求响应时间是1秒，需要大约每秒700k个请求才能达到我们预订的场景。这个数据在生产环境中很容易达到，但是在我们的测试场景中却几乎不可能产生。

这时候读者可能会问，那么你们是怎么实现的呢？我们在POST请求参数中引入了sleep参数，可以通过该参数让服务端休眠特定毫秒之后再返回响应数据。这样能够模拟生产环境中的耗时请求。所以我们设置了休眠20分钟，这样每秒请求数达到583个左右的时候，就能够维持700k个连接数的水位。

除此之外，我们还在向HAProxy发起POST请求的时候引入了另一个参数：times。该参数可以指定服务端在关闭TCP连接之前响应数据的重复次数。这样能够帮助我们模拟产生更多的数据量。