概述
最近有很多朋友来咨询关于阶梯加压与聚合报告中实际请求数的问题。
大家的困惑基本一致，那就是明明自己只设置了几十个线程，最后为什么聚合报告中跑出了上万个请求？
关于这个问题，今天来实际操作并记录一下，解答大家的疑惑。
实验
还是用百度做例子
我们设置阶梯加压线程组的请求参数，如下图
此图表示
1：每隔2秒钟，会在1秒内启动5个线程
2：每次线程加载之后都会运行2s然后开始下一次线程加载
3：最终会加载50个线程并持续运行30s
4：50个线程持续运行30s后，会每隔2秒钟停止5个线程，剩余的线程继续负载。一直到所有线程完全停止
要正确理解最终请求数是如何计算出来的。我们必须知道每一秒钟线程到底释放了多少请求！！
阶梯加压阶段：
如果该请求的平均响应时间是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次
是不是请求数真的就这么精确呢？其实这样计算也是不准确的
因为随着我们的负载越来越大，对服务器资源的消耗也越来越大，请求的响应时间也会越来越长
响应时间越来越长，那么相应的每秒迭代次数就会变少。我们这里的响应时间仅仅取了个平均值，真实的数据肯定会有误差