jmeter 定时器原因

jmeter定时器

一、 定时器的作用域

1. 定时器是在每个sampler（采样器）之前执行的，而不是之后（无论定时器位置在sampler之前还是下面）；

2. 当执行一个sampler之前时，所有当前作用域内的定时器都会被执行；
3. 如果希望定时器仅应用于其中一个sampler，则把定时器作为子节点加入；
4. 如果希望在sampler执行完之后再等待，则可以使用Test Action；

 

针对第1点：

3个线程发送请求：

 

 

 

针对第2点： 

当我们更改固定定时器的地方，再来观看结果：

首先请求会过5秒，才会访问慢查询接口。

 

 

 看线程组1-1 先请求慢查询接口时间是 12：15：14，然后再请求支付接口的时间是:12:15:46,每个线程访问下次请求时确实等了5秒。

针对第4点,目前来看，自己没用上

二、 定时器的作用

1. 固定定时器（Constant Timer）
 

如果你需要让每个线程在请求之前按相同的指定时间停顿，那么可以使用这个定时器；需要注意的是，固定定时器的延时不会计入单个sampler的响应时间，但会计入事务控制器的时间。

对于“java请求”这个sampler来说，定时器相当于loadrunner中的pacing（两次迭代之间的间隔时间）；
对于“事务控制器”来说，定时器相当于loadrunner中的think time（思考时间：实际操作中，模拟真实用户在操作过程中的等待时间）。

我们通常说的响应时间，应该大部分情况下是针对某一个具体的sampler（http请求），而不是针对一组sampler组合的事务 。

 

2. 常数吞吐量定时器（Constant Throughput Timer）

简单点说，就是我相让每次请求结果保持多少吞吐量，比如：

3个线程我想让它保持tps 为30，那么我只需要用到常数吞吐量定时器，常数，常数，常数

案例：

线程数为3，压测30秒

 

 

 

 结果也大概是30个TPS。

可以让JMeter以指定数字的吞吐量（即指定TPS，只是这里要求指定每分钟的执行数，而不是每秒）执行。

吞吐量计算的范围可以为指定为当前线程、当前线程组、所有线程组等范围，并且计算吞吐量的依据可以是最近一次线程的执行时延。这种定时器在特定的场景下，还是很有用的。

 

3. 同步定时器（Synchronizing Timer）

PS：超时时间为0时，默认无超时限制。
 
这个定时器和loadrunner当中的集合点（rendezvous point）作用相似，其作用是：阻塞线程，直到指定的线程数量到达后，再一起释放，可以瞬间产生很大的压力。

（1）Number of Simulated Users to Group by:模拟用户的数量，即指定同时释放的线程数数量
（2）Timeout in milliseconds:超时时间，即超时多少毫秒后同时释放指定的线程数

案例：

50个线程并发，1秒启动，压测30秒：

同步定时器中，集合点为10，0表示会一直等待

 

 观察结果，用表格查看结果：

 

 基本上是达到10个就并发了。

模拟用户组的数量设置，为到集合点释放的线程数

超时时间如果设置为0，线程将会等待线程数达到了设置的值才释放。如果线程数不足集合点中设置的数，就会一直处于等待当中。

如果设置时间大于0，那么如果超过设置的最大等待时间后还没达到模拟用户组中设置的值，线程组将不再等待，释放已到达的线程

 4、统一随机定时器

 

 

该定时器可以在请求之间设置一个随机延时，每个随机延时有相同的发生概率。

• Random Delay Maximum(in milliseconds): 随机延迟最大的时间 单位毫秒
• Constant Delay Offset(in milliseconds):固定延迟时间 单位毫秒

比如下图：

 

 

 

 说明：每5个线程

线程组 1-1 确实是2000+随机  然后再发送请求

线程组1-2 也是如此