在生产环境压测时,可能存在并发设置过高,导致把生产环境资源占满或者服务器打挂,从而影响系统正常使用;或是导致系统触发限频,出现大量报错,从而影响压测结果;于是针对以上问题,我们可以使用jmeter中的Constant Throughput Timer来解决以上问题。
Constant Throughput Timer(常数吞吐量定时器):顾名思义,该定时器的作用主要是控制吞吐量,使其保持总吞吐量(以每分钟样本数表示)尽可能接近给定的数字。当然,如果服务器无法处理它,或者其他计时器或耗时的测试元素阻止它,则吞吐量会低于给定值。
新建jmeter脚本,右键测试计划,添加->定时器->Constant Throughput Timer,创建一个Constant Throughput Timer用于控制吞吐量
配置项 | 说明 |
---|---|
目标吞吐量(每分钟的样本量) | 每分钟能达到的最大吞吐量 |
基于计算吞吐量 | ● 只有此线程- 每个线程将尝试保持目标吞吐量。总吞吐量为目标吞吐量除以60秒乘以线程数。 ● 当前线程组中的所有活动线程- 目标吞吐量在组中的所有活动线程之间分配。每个线程将根据需要延迟,基于它上次运行的时间。 ● 所有活动线程- 目标吞吐量在所有线程组中的所有活动线程之间分配。每个线程将根据需要延迟,基于它上次运行的时间。在这种情况下,每个其他线程组都需要一个具有相同设置的恒定吞吐量计时器。 ● 当前线程组(共享)中的所有活动线程- 如上所述,但每个线程根据组中任何线程上次运行的时间而延迟。 ● 所有活动线程(共享) - 如上所述;每个线程的延迟基于任何线程上次运行的时间 |
注:吞吐量限制影响的一定是线程,和多少个请求没有关系,所以这里的定时器需要注意如果是只想限制一个线程组,需要将定时器放入线程组中
可能对上述基于计算吞吐量中的5个选项不太理解,这里对每个选项进行详细说明
只有此线程:
我们这里目标吞吐量填写60,基于计算吞吐量选择“只有此线程”,线程数设置为10线程,这里的总吞吐量应该为60➗60(s)✖️10=10/sec(如果使用分布式jmeter,那总吞吐量为节点数乘以限制的吞吐量)
实际结果如下:
由此可以看出,总吞吐量为目标吞吐量除以60秒乘以线程数。
所有活动线程:
我们这里目标吞吐量填写60,基于计算吞吐量选择“所有活动线程”,线程数设置为10线程,这里的总吞吐量应该为60➗60(s)=1/sec(如果使用分布式jmeter,那总吞吐量为节点数乘以限制的吞吐量)
实际结果如下:
由此可以看出,总吞吐量为目标吞吐量除以60秒(如果有多个线程组,这里的总吞吐量为所有线程组之和)。
当前线程组中的所有活动线程:
我们这里目标吞吐量填写60,基于计算吞吐量选择“当前线程组中的所有活动线程”,线程数设置为10线程,这里的总吞吐量应该为60➗60(s)=1/sec(如果使用分布式jmeter,那总吞吐量为节点数乘以限制的吞吐量)
实际结果如下:
由此可见,总吞吐量为目标吞吐量除以60秒(如果有多个线程组,这里的总吞吐量为目标吞吐量乘以线程组个数)。
所有活动线程(共享):
与“所有活动线程”的选项基本相同。唯一区别是,每个线程会根据组中任何线程上次运行的时间而延迟
当前线程组中的所有活动线程(共享):
与“当前线程组中的所有活动线程”的选项基本相同。唯一区别是,每个线程的延迟会基于任何线程上次运行的时间而延迟
在使用常数吞吐量定时器时需要注意使用场景,选择合适的计算吞吐量方式。
共享和非共享都旨在产生所需的吞吐量,并将产生类似的结果。
共享的准确性会更高于非共享的准确性。
非共享适用于在线程之间生成更均匀的事务传播。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。