Jmeter之负载测试Stepping Thread Group 逐步增加并发数 阶梯式加压并发

首先，需要安装两个插件，请参考另一篇博文：Jmeter监听器扩展操作步骤_小骨格子屋-CSDN博客_jmeter添加监听器

其次，在测试计划中选择Stepping Thread Group线程组

Stepping Thread Group中参数介绍

This group will start 100 threads：设置线程组启动的线程总数为100个

First,wait for N seconds：启动第一个线程之前，需要等待N秒

Then start N threads：设置最开始时启动N个线程

Next,add 10 threads every 30 seconds,using ramp-up 5 seconds：接下来，每30秒添加10个线程，在5秒的时间段

Then hold load for 60 seconds：启动的线程总数达到最大值之后，再持续运行60秒

Finally,stop 5 threads every 1 seconds

结合Active Threads Over Time

运行Stepping Thread Group需要和Active Threads Over Time结合起来使用，这样能看到动态的阶梯加压效果
可以看到和Stepping Thread Group负载预览图基本一致，证明加压效果是正常的

那为什么自己只设置了几十个线程，最后为什么聚合报告中却跑出了上万个请求？

阶梯加压阶段

如果该请求的平均响应时间是 100ms，那么一秒内就可以迭代 10 次
那么，这 1 秒内我如果启动了 5 个线程，那么这 1s 内发出的请求数就是 5*10=50 次
接着，它运行了 2s 钟才开始加载下一波线程。在这 2 秒之内，它发出的请求数是 2*5*10=100 次
在 2s 之后，线程组又在 1s 内释放了 5 个请求，并运行了 2s。那么在这 2s 内，它发出的请求是 2*10*10=200 次（此时是 10 个线程在运行）
以此类推，一直到 50 个线程加载完之前，我们的线程组释放的请求数是这样的
(2*5*10)+(2*10*10)+(2*15*10)+(2*20*10)+(2*25*10)+....+(2*45*10)=4500 次

持续负载阶段

注意：为什么最后不是 2*50*10？因为从 50 个线程加载完之后，我们进行的是 30s 的持续负载
这 30s内，我们的总的请求数是30*50*10=15000

线程释放阶段
在 30s 负载结束之后，我们的线程组开始阶梯式释放
此时，即使是线程组在释放，那么剩余的线程依然在发起请求
(2*45*10)+(2*40*10)+(2*35*10)+(2*30*10)+(2*25*10)+....+(2*5*10)=4500 次
总的请求数=4500+15000+4500=24000 次
是不是请求数真的就这么精确呢？其实这样计算也是不准确的
因为随着我们的负载越来越大，对服务器资源的消耗也越来越大，请求的响应时间也会越来越长
响应时间越来越长，那么相应的每秒迭代次数就会变少。我们这里的响应时间仅仅取了个平均值，真实的数据肯定会有误差