『动善时』JMeter基础 — 53、JMeter集合点功能的使用-编程思维

『动善时』JMeter基础 — 53、JMeter集合点功能的使用

1、集合点介绍

“性能测试”一般思路是“多用户并发测试”,但真正的并发其实是不存在的,为了更真实、更接近的实现并发,在需要压力的地方设置集合点,等所有用户都到位的时候,然后一起访问,从而实现并发。

举个例子,要测试100个用户同时登录,每到输入用户名和密码登录的地方,所有的虚拟用户都相互等待,等100个用户都输入完毕,相当于集结在一起了 ,然后再一起访问。

(1)集合点含义

集合点可以简单得理解为一种控制虚拟用户行为的机制,该机制可以达到效果是:在一定时间范围内,将一定数量的虚拟用户,阻挡在一个操作行为点前的位置,进行互相等待。在条件(达到虚拟用户数量或超时)到达后,唤醒全部等待中的虚拟用户。从而达到,使一定数量的虚拟用户,可以同时进入下一个操作行为点的目的。

(2)集合点作用

让所有请求在不满足条件的时候处于等待状态,等待满足条件后,再同时一起发起请求。也就是模拟让所有用户,恰好在同一时刻执行任务,进行同步并发。常用在并发测试或压力测试中。

在实际工作中,往往初衷是为了实现最大意义上的并发,来考察系统应对此种极端情况的表现。

常见应用场景:秒杀。

提示:实现集合点的组件为同步定时器。

2、同步定时器界面介绍

Synchronizing Timer组件翻译过来叫同步定时器。

添加同步定时器组件方式:选中“取样器”右键 —> 添加 —> 定时器 —> Synchronizing Timer

界面内容如下图所示:

image

同步定时器界面详细说明:

  • 名称同步定时器组件的自定义名称,见名知意最好。
  • 注释:即添加一些备注信息,对该同步定时器组件的简短说明,以便后期回顾时查看。
  • 模拟用户组的数量(Number of Simulated Users to Group by):一次集合多少用户后再执行请求。也就是设置模拟并发请求的线程数。
    如果设置为0,默认等于线程组元件中设置的线程数。
  • 超时时间以毫秒为单位(Timeout in milliseconds):集合这些用户所花费的时间。
    1)设置为0,无限等待,直到达到集合点设置的线程数。
    2)设置指定时长,如果到达指定时长,集合点数量未到达,这时该集合中有多少用户,就释放多少用户数量。

提示

  • 如果设置Timeout in milliseconds为0,且线程数量无法达到Number of Simultaneous Users to Group by中设置的值,那么测试将无限等待,除非手动终止。(可能会导致程序挂起)
  • 同步定时器组件仅作用于同一个线程组,所以如果使用并发测试,确保Number of Simultaneous Users to Group by中设置的值,不大于它所在线程组设定的用户数。(集合数最好能被线程组中设置的线程数整除)
  • 集合时间最好大于等于线程组中的启动时间。当集合线程数不能被线程组的线程数整除时,集合时间不要设置为0。
  • 作用域:当执行一个Sampler之前时,和Sampler处于相同作用域的定时器都会被执行。如果希望定时器仅应用于其中一个Sampler,则把该定时器作为子节点加入。

3、集合点的使用

例如:现在有一个需求,实现批量用户进行部门查询操作。

(1)测试计划内包含的元件

添加元件操作步骤

  1. 创建测试计划
  2. 创建线程组:选中“测试计划”右键 —> 添加 —> 线程(用户) —> 线程组
  3. 在线程组中,添加取样器”HTTP请求“组件:选中“线程组”右键 —> 添加 —> 取样器 —> HTTP请求
  4. 在取样器中,添加定时器Synchronizing Timer组件:选中“取样器”右键 —> 添加 —> 前置处理器 —>Synchronizing Timer
  5. 在线程组中,添加监听器察看结果树组件:选中“线程组”右键 —> 添加 —> 监听器 —> 察看结果树

最终测试计划中的元件如下:

image

点击运行按钮,会提示你先保存该脚本,脚本保存完成后会直接自动运行该脚本。

(2)线程组元件内容

设置该线程组的线程数为50,来模拟50个用户进行数据的查询。

下图中的设置为,在1秒内启动50个线程。

image

(3)HTTP请求组件内容

一个查询请求的基本编辑,如下图所示:

image

(4)同步定时器内容

我们设置同步定时器为:

  • 集合数为50:和线程组设定的线程数相同。
  • 集合等待时间设置为3秒:集合等待时间大于线程组中所有线程的启动时间。

界面内容如下:

image

(5)运行脚本查看结果

下图为脚本的运行结果,这样看没有什么意义,一般要配合聚合报告组件查看。

image

提示:聚合报告内容下一篇文章详细说明。

4、集合点设置情况说明

  • 场景一:
    线程数设置为10,集合点为5,超时为0。
    会看到有10个结果,此处分成了2组进行并发,每次是5个用户。
  • 场景二:
    线程数设置3,集合点设置为4,超时为0。
    发现没有执行请求,需要手动stop脚本的运行。原因:不够并发数且超时设置为0。
  • 场景三:
    线程数设置6,集合点设置为4,超时为0。
    发现只有4个请求,然后一直都没有停止,需要手动stop脚本的运行。原因:第一组够集合点,一起并发,第二组只有2个,不够集合点,且设置超时为0。
  • 场景四:
    线程数设置6,集合点设置为6,超时为0。
    可以看到有6个请求。分1组执行。
  • 场景五:
    线程数设置6,集合点设置为4,超时为5000,点击运行。
    分2组执行,发现先有4个请求,为第一组,5秒后,出现后2个请求,为第二组,共6个。

5、集合点总结

集合点最关键的就是策略问题,涉及到两个方面:

  1. 同步并发时机问题:即什么时候同步并发?
  2. 超时问题:比如目的是达到100个用户时,才向服务器发请求,而这个过程中存在一个超时问题,可能是从第50个并发到第100个并发之间超时了,超时怎么处理?

正确使用集合点:

首先,测试场景的设计中加入集合点,实际上是在忽略ThinkTime(思考时间)和KeyTime的情况下,已经可以叫并发测试了,而且效果也完全达到了预期。

另外,建议将大事务拆解为更加短小精悍的几个小事务,并且通过分组运行调节这些事务之间的关系,比如一个组可以跑整个大事务,或者一些组按大小事务混合跑。在这种情况下精选几个关键性业务的事务组合,并放入集合点。然后一个一个的在压力背景环境下运行测试,重点关注它们的真正并发表现。

参考:

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议 转载请注明原文链接: https://www.cnblogs.com/liuyuelinfighting/p/14986660.html