Jmeter阶梯加压找到性能拐点

一、压力测试理解

大部分同学都有使用jmeter做压力测试的经验，那么请问：怎么做压力测试？大家可能会回答：“加线程组，加并发，查看结果树或者聚合报告”。那么请问什么是压力呢？
在我们实际工作中，压力通常用RPS来表示。RPS（Request Per Second）每秒钟的请求数，它代表对服务器实际发出压力的大小。
RPS由并发数，和服务器的响应时间（RT）决定，他们之间的计算公式为：并发数=RPS*RT

二、对****首页进行压测

1、设置线程组信息（设置200个线程，不限制迭代次数）

2、新建首页HTTP请求，在该请求下添加Throughput Shaping Timer（吞吐量控制器）：用来控制吞吐量的控制器，通过延缓线程运行来整体控制取样器产生的RPS

Jmeter没有Throughput Shaping Timer插件需要去官网下载：
下载地址：https://jmeter-plugins.org/?search=jpgc-tst
下载插件后放在jmeter的目录lib/ext下面，重启Jmeter

3、在Timer下方添加Throughput Shaping Timer（大家也可以下载汉化版本便于理解）：

4、配置Throughput Shaping Timer

0-10s:RPS请求从1逐步增加到200
10-30s：RPS请求从200逐步增加到400
…
120-180s：RPS为1000/s持续一分钟
每当我们主动增加一行信息，下方的折线图会实时变动，代表着阶段性RPS请求数变化

5、添加监听器
除了平时常用的结果树和聚合报告，我们也可以使用：Transaction per Second / Hits per Second / Response Times Over Time / Active Threads Over Time…每一个都能监听特定指标在运行过程中的变化
在这里我们添加三个监听器：TPS，HPS，RT
TPS：分析吞吐量
HPS：单位时间的点击率，可以理解为用户触发的请求数
RT：整个事务运行期间的响应时间

如果有同学发现Listener下方没有上述的监听器，不要紧张，先百度，如果还没有找到答案，请到官网下载Plugins-Standard和Plugins-Extras两个插件，丢到ext目录下，然后再重启。

三、运行并分析结果

终于到运行这步了，撒花✿✿ヽ(°▽°)ノ✿

3.1 首先分析Hits per Second，在1分10秒之前，RPS逐步增长，有同学会问，怎么会是RPS？不是HPS吗？因为在单接口请求下，我么可以认为HPS和RPS是相等的。

3.2 在1分10s这个节点，最大RPS=662/s（测试环境相当好的一个数据了，给游卡点赞），可以理解为：最大支持1秒内662个用户同时访问****的首页。

3.3 还记得我们文章开头处的公式吗？并发数=RPS*RT

我们的RT是0.263s（也是比较正常的一个数值），这时候可能会有同学说，你这里不能取平均时间，不具有代表性，我们还应该考虑90%,95%，99%不同比例的接口响应时间。对的，个人认为，这些数值在和平均值没有过大的区别的情况下，我们可以取平均值来计算，如果说出现了较大的波动，那么我们需要考虑是不是服务器的内存,cpu出现了问题。

这里我们算下并发数：662*0.263=174，可以理解为：****的首页支持174个用户在1s内不断的刷新首页。

3.4 我们大家看下TPS（服务器每秒处理的事务数）这张图：

虽然服务器在31s之后出现了较大的波动，但是一直都是success的，没有报错。

我们加大RPS的请求数，缩短时间，再来一波：

查看结果：

还是没有报错，我们服务器这么厉害的吗，心中越来越怀疑，可能是哪里弄错了。

我们点击其中的一个请求：

code的值为1，也被识别成功了，心中万马奔腾。。。。

我们乖乖的加个简单的断言–“code”:0

再跑一下：

惊不惊喜，意不意外，从3s以后，就开始有绿色的折线图（代表失败），应该是测试环境已经崩掉了。需要重启下服务器。正常情况下，在开始出现绿色拐点处，代表服务器每秒处理事务的极限。

这时候有同学问了，我们不是还应该观察服务器cpu，内存，I/O的变化吗？这个可以有的，需要在服务器上装个插件，就能在一个可视化的页面上看到各项指标随着RPS的增加而实时变动的折线图。

四：总结

这篇随笔简单的记录了****首页接口的压力测试过程，可能有一些遗漏和说错的地方，估计日后回过头来再看时，心中自然冒出一句：这个菜鸡…
Jmeter还可以做接口测试，还可以读取csv，还可以自定义脚本，自定义变量…各种各样的插件，功能非常强大，希望大家能一起学习进步。