vegeta工具性能压测指南

高QPS性能测试工具

阅读本文你将可能知道什么：

1. 理解vegeta的压测原理和设计目的，并且以正确的姿势使用该工具。
2. 解读vegeta的报告并通过笔者实际测试经验合理的设置压测参数。
3. 学会使用vegeta压测https的GET请求和POST请求。（虽然vegeta的说明文档中也有写）

阅读本文你将无法知道什么：

1. 本文不会详述网络测试整个模型，测试指标之间的关联性。如果你不太清楚如何进行网络测试，或者你不理解并发，响应时间，每秒的访问请求。那么请你先看看我之前写的博客七层网络性能基准测试中的协调遗漏问题–Coordinated Omission
2. 本文不会详述vegeta的安装过程。如果有需要实际尝试的推荐直接下载[vegeta的github上预编译好的可执行包，]解压即可使用。(https://github.com/tsenart/vegeta/releases)
3. 本文不会详述vegeta的操作指令，这个笔者认为vegeta的github已经说得很清楚了。详情可以查看该链接：vegeta

vegeta是一个高性能的http（s）负载测试工具。虽然没有办法保持你想要的并发连接数，但是它能够尽全力的尽可能发送请求。所以在测试定量的QPS下笔者认为这实在是一个非常好的性能测试工具。笔者要重新声明vegeta开发者（Tomás Senart）想说的一点：vegeta是一个负载测试工具而不是一个基准测试工具。基准测试试图找到系统在峰值容量下所能承载的极限，而负载测试则倾向于讲述系统在不同的负载点和配置下的表现。

vegeta可以做什么：

1. 尽可能的发送你指定的访问请求速率。
2. 如果一台压力机没有办法发送你想要指定的请求速率则可以通过pdsh工具+vegeta来进行分布式压测。最后统计结果生成报告。

vegeta不能做什么：

1. vegeta无法指定在固定的并发连接数下发送指定的请求速率。所以vegeta发送指定的请求速率会以延时最小的方式来尽可能少的建立起并发连接数。vegeta的attack参数中有一个“-connections”，这个参数指的是打开最大的空余链接，但是随着测试的进行这些空余链接有多少会被使用是由vegeta来决定的。所以不要指望vegeta来测试固定并发下的QPS，如果想那样做建议使用wrk2。
2. vegeta无法像loadrunner那样指定每秒钟兴建多少并发链接来执行压测任务。所以vegeta也就没有办法很好的观测到新建并发连接数。

vegeta压测http网站的静态请求

vegeta的指令主要分为这几类：

1. 整体环境变量参数：该类参数控制主要控制压测时用多少cpu来执行任务。
2. 攻击指令参数：该类参数主要控制请求体内容与请求速率。
3. 报告生成参数：该类参数主要控制输出报告格式与内容。这类中主要包含了report command，encode command，plot command。

压测一个webserver的静态页面通用的命令如下：

echo "GET http://10.130.1.107" | vegeta attack  -rate=19000  -duration=60s | tee houminxi.bin | vegeta report  -output houminxi-result.bin
#echo "GET http://10.130.1.107"为请求体
# vegeta attack  -rate=19000  -duration=60s 
#vegeta的压测部分，以19000每秒的QPS（query per second）来访问目标服务器，执行时间是60s。
#tee houminxi.bin 
#将vegeta的请求结果以二进制的格式保存起来。这个文件最主要的作用是如果你以后分布式执行压测，那么最后使用vegeta report统计结果的时候则需要使用每台压测机器上该文件。
#vegeta report  -output houminxi-result.bin
#将本台机器上压测结束后的结果以可阅读的形式打印出来。

值得提一下的就是如果是分布式压测最后统计结果生成报告的话，应该是将每台压力机的houminxi.bin拷贝到同一台机器的相同路径下。使用vegeta report houminxi.bin houminxi-1.bin | less（记得拷贝过来将结果文件houminxi.bin重命名，以免覆盖其他机器拷贝过来结果文件。vegeta report 后面每个文件以空格的形式分开，使用less命令是万一压测请求出错。这样不至于你合成结果就是一堆错误糊脸。单台压力机中使用tee命令保存的二进制结果文件和你生成报告的文件不要重名，要不就被覆盖了。或者当你想使用分布式压测的时候不使用vegeta report命令，为了防止文件冲突。

vegeta压测https请求

echo "GET https://10.130.1.227:443" | vegeta attack -cert /root/cs/cs1.pem  -key /root/cs/cs2.pem -rate=4000  -duration=60s | tee results.bin | vegeta report  -output result.bin
#-cert指定的是你webserver的证书，如果你有私钥的话你也可以使用-key来指定你webserver的私钥。

另外一种你不需要在vegeta命令行中指定ssl证书的方式就是将该证书添加到你机器的根信任证书中。

cat  /root/cs/cs1.pem >> /etc/pki/tls/certs/ca-bundle.crt

vegeta压测https的post请求

post请求要按照webserver所给出的格式来填写对应的路径和请求参数。vegeta提供-targets来读取你在文本内所定义的目标请求端。提供-body指定一个文件，该文件的内容将被设置为每个请求的主体，注意请求主题如果在body中指定了就不要在target的文件中指定了，否则会被target文件中的设置所覆盖。

这里我定义target.txt写入的工具目标路径如下：

POST http://10.130.2.216:8080/api/v5/micro/new/lock

定义body.josn定义携带参数如下：

{
        "access_token":"",
        "cts_token":"",
     	"en_basedata":"",
        "en_data":"",
        "key_id":""
}

则使用vegeta压测时的命令如下：

vegeta -cpus 24   attack -targets tatget.txt  -body body.json -timeout=20s -rate 500   -duration=300s  | vegeta report -output result.bin

vegeta指定QPS速率建议

既然vegeta主要是以压测QPS为主的工具，那么一台vegeta在实际压测的时候设定多少QPS合适。是不是需要加分布式来完成压测任务，成为了一个测试工程师需要考虑的因素。博主在实际测试优化nginx服务器的时候得出来的vegeta压测报告如下，仅供参考。

这里主要注意当vegeta只有一台的时候压测nginx最高只能到30000W的QPS。但是随着压力机的增多，nginx服务器所能承载的最大QPS能到13.8W。如何区分是不是需要增加压力机来满足测试呢？

在vegeta的报告中如会有请求status codes的分布。如果状态为“0”的请求分布比较多的时候，代表着这些请求没有在压力机发出整个测试就结束了。这里需要考虑有两点：

1. 是否是被测端过饱和了导致更多的请求无法被接收到。
2. 是否压力机太少了导致压力机产生了额定的请求速率但是没有发送出去。
3. 这里不需要考虑测试的执行时间问题。因为压测端的请求速率是恒定的，如果说有status codes等于“0”的情况，你随着增加测试时间status codes等于“0”的个数只会越来越多。

博主使用的4核8GB内存的虚拟机来进行的压测。在这种规格的虚机下使用vegeta去压测一个静态页面时，rate指定超过3W会使虚机本身成为压力瓶颈。

失速点的状态考察

vegeta的作者都说了这个是用来做压力测试的不是做基准测试的。但是基准测试也算在压力测试里面吧。那我要做基准测试，判定系统所能处理的最大QPS在什么程度该怎么办呢？为了解决这个问题在最新版本的vegeta结果报告中第一行的表述做了一些改动。在v12.7.0的版本中结果报告里Requests增加了rate和throughput。这两个结果值的解释分别如下：
rate：在发起压测过程中vegeta实际发送的请求速率。
throughput：以服务器的角度描述成功处理请求的速度。

所以当你压测一个网络系统，如果你压测时指定的请求rate速率没有超过网络系统承载的极限。那么在vegeta压测命令中你指定的rate略大于报告结果中的rate。报告结果中的rate略大于throughput，但是两者差别不大。

如果你压测时指定的请求rate速率超过了网络系统的承载极限。那么在vegeta压测命令中你指定的rate远大于报告结果中的rate。报告结果中的rate远大于throughput。

可以看到当我用五台压力机压测15W的QPS时，测试报告实际的rate只有9W，而服务器成功正常处理的请求速率只在2.3W。这种情况就是系统的一个失速情况。15W的QPS超过了nginx服务器的处理能力。则只会有越来越多的请求在排队等待，而这种请求排队从测试数据上可以判断不是客户端数量造成的，而是服务器确实处理不完了。