测试驿栈-由浅入深学性能 性能测试连载 (13)-深度剖析阶梯加压与最终请求数
性能答疑 QQ 群:697244251
什么是阶梯加压
阶梯加压是压力测试中的一个子集。它可以阶梯式的形式释放压力,以此测试服务器的性能。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 次
是不是请求数真的就这么精确呢?其实这样计算也是不准确的
因为随着我们的负载越来越大,对服务器资源的消耗也越来越大,请求的响应时间也会越来越长
响应时间越来越长,那么相应的每秒迭代次数就会变少。我们这里的响应时间仅仅取了个平均值,真实的数据肯定会有误差