性能测试连载 (13)-深度剖析阶梯加压与最终请求数

https://pan.baidu.com/s/1df1HDkFzChYNAbsSazizpw 提取码：hhn7
jmeter 全系列文档资料

https://pan.baidu.com/s/1rD3H9EGbu0u11E8ofpAl3A 提取码：8q65
性能测试初级到高级系列资料

什么是阶梯加压

阶梯加压是压力测试中的一个子集。它可以阶梯式的形式释放压力，以此测试服务器的性能。jmeter 中提供了阶梯加压线程组来满足我们的需求。

 

 

 

1-1
图 1-1 名词解释
this group will start：表示总共要启动的线程数，如图：设置 200 个，表示最终会加载 200 个线程
first，wait for：第一个线程的加载等待时间，如图：设置为 0 秒，表示立即启动线程
then start：初次加载多少个线程，如图：设置为 0 个，表示初次不加载线程
next add：每次加载多少个线程，如图：设置为 20 个，表示每个梯次加载 20 个线程
threads every：当前运行多长时间后再次加载线程，及每一次加载完成之后的持续时间，如图：设置为 5 秒，每梯次加载完线程之后运行 5 秒
using ramp-up：加载线程的时间，如图：设置为 0 秒，表示每一次加载立刻完成
then hold load for：线程全部加载完之后运行多长时间，如图：设置为 50 秒，表示最后 200 个线程加载完之后再持续 50 秒
finally，stop/threads every：每多长时间释放多少个线程，如图：设置为 20 个和 5 秒，表示所有持续负载结束之后每 5 秒钟释放 20 个线程。剩余的线程继续加载请求
注意：阶梯加压线程组需要和 Active Threads Over Time(不同时间活动数量展示) 结合起来，这样能看到动态的阶梯加压效果

 

 

阶梯加压与请求释放

概述

有很多初学者对阶梯加压与聚合报告中实际请求数感到困惑。大家的困惑基本一致，那就是明明自己只设置了几十个线程，最后为什么聚合报告中跑出了上万个请求？
实验
用百度做例子，设置阶梯加压线程组的请求参数，如图 1-2

 

 

此图表示
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 次
 
是不是请求数真的就这么精确呢？其实这样计算也是不准确的
因为随着我们的负载越来越大，对服务器资源的消耗也越来越大，请求的响应时间也会越来越长
响应时间越来越长，那么相应的每秒迭代次数就会变少。我们这里的响应时间仅仅取了个平均值，真实的数据肯定会有误差