引言:
综合场景执行的最终比例决定着性能测试结果的有效性。
Throughput Contoller,直译是吞吐量控制器,它是用来控制该控制器下面元件的执行次数,与控制吞吐量的功能无关。(注:用Constant Throughput Timer可以控制吞吐量,不建议使用此插件去控制综合场景比例)
Throughput Contoller有两种模式:Total Executions 和Percent Executions,如下图,在红色区域框重选择即可。
参数说明如下:
- Total Executions:按吞吐量值来指定执行次数。选择此模式,吞吐量值的单位为“次”。
- Percent Executions:按百分比来指定执行次数。选择此模式,吞吐量值的单位为“%”。
上面说的两个指标从字面上很好理解,那勾选的per user是啥意思呢,我们可以做一些实验研究下:
首先使用percent模式进行实验:
场景设计如下,所有模式都设置20线程,迭代100次,throughput设置分为A(10%),B(90%)两个大模块,其中A下的两个接口A1(10%),A2(90%),B下的两个接口B1(10%),B2(90%),不勾选per user,结果如下:
label | samples | throughput |
---|---|---|
A1 | 20 | 14.6 |
A2 | 180 | 109 |
B1 | 179 | 107.7 |
B2 | 1620 | 940.8 |
再看勾选的结果:
label | samples | throughput |
---|---|---|
A1 | 20 | 19.7 |
A2 | 180 | 109.6 |
B1 | 180 | 109.7 |
B2 | 1620 | 937.5 |
可以说各项指标非常接近,我认为在percent模式下,vuser是否对结果无影响!
再看excutions模式,勾选per user:
label | samples | throughput |
---|---|---|
A1 | 200 | 137.1 |
A2 | 200 | 137.9 |
B1 | 200 | 138.2 |
B2 | 1800 | 865.4 |
不勾选per user:
label | samples | throughput |
---|---|---|
A1 | 10 | 55.6 |
A2 | 10 | 56.8 |
B1 | 59 | 70 |
B2 | 90 | 107.9 |
这么来看,差异就非常明显了
分析数据,得出结论:
- 当勾选Per User时:
- 线程数*循环次数>=线程数*吞吐量时,Total Executions模式的执行次数=线程数*吞吐量。
- 当线程数*循环次数<线程数*吞吐量时,Total Executions模式的执行次数=当线程数*循环次数。
- 当不勾选Per User时:
- 线程数*循环次数<=吞吐量时,Total Executions模式的执行次数=线程数*循环次数。
- 当线程数*循环次数>吞吐量时,Total Executions模式的执行次数=吞吐量。
第二种模式其实蛮绕的,我么绝大数情况下,第一种模式即可!
补充一点,jmeter的插件都是有性能损耗的,在我的试验下,该插件也存在10%左右的性能损耗,一些网上的帖子有通过随机算法控制区间来间接去控制综合场景的比例,虽然理论上没有问题,但大家也可自行去评估下性能损耗。
最后想问个问题,为什么我的demo里面要设置两个层级的throughput控制器,这样做的现实意义是啥?欢迎大家留言!
点赞,转发,评论人间三大真情!