Jmeter之集合点(Synchronizing timer 同步定时器)

本文深入探讨了JMeter中集合点的使用方法及其在性能测试中的关键作用。通过对比LoadRunner,介绍了SynchronizingTimer如何模拟多用户并发,详细解析了集合点参数设定及其对测试场景的影响,并通过实例演示了不同配置下的测试结果差异。

1.集合点介绍

LR中集合点可以设置多个虚拟用户等待到一个点,同时触发一个事务,以达到模拟真实环境下多个用户同时操作,实现性能测试的最终目的。
jmeter中使用Synchronizing Timer实现Lr中集合点的功能,模拟多用户并发测试,即多个线程在同一时刻并发请求。
jmeter中使用集合点的方法:Synchronizing Timer。

2.集合点参数介绍

  • 启动方法

  • 参数介绍

模拟用户组的数量(Number of Simulated Users to Group by):集合多少人后再执行请求(也就是执行的线程数)
      注意:等同于设置为线程租中的线程数,一定要确保设置的值不大于它所在线程组包含的用户数(一般是线程组是多少用户集合点这里就是多少用户)。

超时时间以毫秒为单位(Timeout in milliseconds):指定人数 多少秒没集合到算超时(设置延迟时间以毫秒为单位)
    注意:如果设置Timeout in milliseconds为0,表示无超时时间,会一直等下去。
    线程数量无法达到"Number of Simultaneous Users to Group by"中设置的值,那么Test将无限等待,除非手动终止。

3.场景介绍

  下面以三个sampler为列

3.1 场景一:设置定时器与不设置定时器区别

  • 线程数设置为10,集合点为10,超时为1000,点击运行

L3Byb3h5L2h0dHBzL2ltZzIwMTguY25ibG9ncy5jb20vYmxvZy8xMzE1NDYzLzIwMTkwMy8xMzE1NDYzLTIwMTkwMzA1MTU1OTIwMzU5LTIyNzk0MjE0OC5wbmc=.jpg

  • 关闭定时器,发送前期都是零零散散的

3.2 定时器位置是否影响结果

定时器移动到sampler1,结果与3.1一样,如下图所示,所以,不管移动到什么位置,发现只要在该线程组下,都是作用于该线程组下所有请求线程

3.3 移动到子节点下面是什么情况呢,从下面的数据发现是作用于该父类节点的sampler

定时器仅仅对sampler1起作用,即仅在sampler1执行前执行定时器,和sampler2及sampler3无关

注意点:

-----集合点的位置一定要在Sample(采样器)之前才能生效吗???”
   在Jmeter中,timer是在sampler之前执行的。不管这个定时器的位置放在sampler之后,还是之前。当然,如果有多个timer的时候,在相同作用域下,会按上下顺序执行timer,这个就需要慎重放置timer的顺序;不过,为了更好的可读性,还是建议将timer放在对应的sampler前面 或 子节点中。

### JMeter 同步定时器与 LoadRunner 集合点的集合原理对比 JMeter 的 **Synchronizing Timer** 和 LoadRunner 的 **集合点(Rendezvous Point)** 都用于实现虚拟用户的并发请求,但其内部实现机制和行为特征存在一些差异。 #### 1. 基本功能对比 JMeterSynchronizing Timer 允许设定一个“集合点”,当虚拟用户(线程)到达该点时暂停,直到达到指定数量的用户数才一起释放,从而实现并发请求。该机制类似于 LoadRunner 中的 Rendezvous Point,即在脚本中设置一个同步点,让多个虚拟用户在此等待,直到达到预设的并发数后统一执行后续操作[^1]。 #### 2. 集合行为差异 在 JMeter 中,Synchronizing Timer 是基于线程(用户)数量进行集合的。当线程到达该定时器时会阻塞,直到达到“模拟用户组的数量”参数所设定的值,或超时时间到达。如果未设置超时时间(默认为 0),则线程会无限等待,直到满足并发数条件为止。 LoadRunner 的 Rendezvous Point 则支持更灵活的并发控制策略,包括按比例触发、按时间间隔触发等。它可以基于事务的开始、结束或特定的脚本逻辑进行集合,且在分布式测试环境中具有更强的协调能力。 #### 3. 超时机制对比 JMeterSynchronizing Timer 提供了“超时时间(毫秒)”参数,用于控制线程在未达到并发数时的最大等待时间。如果设置了超时时间,线程在等待超时后将不再继续等待,并释放当前已集合的线程。若两个条件(并发数和超时)同时满足,则优先执行满足条件的那个[^3]。 LoadRunner 的集合点也支持超时设置,但其处理方式更为复杂,支持基于事务状态、响应时间或用户组状态的综合判断,适用于更复杂的性能测试场景。 #### 4. 实际并发控制的差异 JMeter 的并发控制依赖于线程组的配置和定时器的组合使用。例如,若线程组设置为 100 个线程,Synchronizing Timer 设置为 50,则每 50 个线程到达后会并发执行一次请求,共执行两次。这种方式适合模拟分批并发请求的场景[^1]。 LoadRunner 的并发控制则更偏向于全局协调,支持在测试过程中动态调整集合点的行为,例如根据当前系统负载、服务器响应时间等动态调整并发用户数,具备更强的灵活性和适应性。 #### 5. 性能与资源消耗 JMeterSynchronizing Timer 在高并发场景下可能会导致资源瓶颈,因为线程需要在内存中等待,且不释放资源。若未设置合理的超时时间,可能导致大量线程阻塞,进而影响测试执行效率[^3]。 LoadRunner 在资源调度方面表现更优,尤其是在分布式测试环境中,能够更有效地管理并发用户和集合点之间的协调,减少本地资源的占用。 #### 6. 分布式测试支持 JMeterSynchronizing Timer 在分布式测试中存在局限性,因为它无法跨节点协调线程集合。每个节点上的集合是独立的,无法实现全局并发控制。若需实现跨节点的集合行为,需要额外的协调机制或自定义脚本支持。 LoadRunner 的集合点支持跨负载生成器的同步,能够实现真正的分布式并发测试,适用于大规模性能测试场景。 --- ### 示例配置(JMeter) ```yaml Thread Group: Number of Threads (users): 100 Ramp-up period (seconds): 1 Loop Count: 1 HTTP Request: Protocol: https Server Name or IP: example.com Path: /login Method: POST Parameters: username: testuser password: testpass Synchronizing Timer: Simulated User Group Size: 50 Timeout in milliseconds: 5000 ``` --- ### 总结 JMeterSynchronizing Timer 和 LoadRunner 的 Rendezvous Point 都用于实现虚拟用户的并发请求,但在并发控制策略、超时机制、资源消耗和分布式支持方面存在显著差异。JMeter 更适合中小型并发测试场景,而 LoadRunner 在大规模、复杂性能测试中具备更强的灵活性和协调能力。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值