jmeter--定时器组件

工作中，用jmeter写接口测试脚本、性能测试脚本时，通常也会用到定时器组件，一般用的比较多的还是固定定时器、同步定时器。对于其他的定时器了解的不是特别深，为了更系统更深入的学习jmeter工具和工具中的定时器组件，自己对一些经常使用的定时器组件进行了学习、探索，并记录了一些知识点。

在JMeter中定时器用来设置延时和同步，以调节请求的发送速率，这里介绍一些常用的定时器组件，包括：固定定时器、jp@gc-throughput shaping timer、bean shell timer、constant throughput timer、synchronizing timer、uniform random timer

所有定时器的统一规则：

（1）     任何类型的定时器，可以放在线程下方、放在线程组下方、放在testplan 下方。

放在线程下方：此定时器只作用于此线程

放在线程组下方：此定时器作用于此线程组下的所有线程

放在testplan 下方：此定时器作用于testplan下的所有线程组（即每个线程组的每隔线程）

（2）     任何类型的定时器，在放置时，是不分前后的，例如下图，定时器和一个线程组在同一级，但是在线程组的下面，在执行此线程组中的请求时，也同样是先执行定时器，再执行请求。

（3）     每个testplan、线程组、线程下方都可以放多个定时器。多个定时器的情况下，延迟时间是根据定时器进行累加的，例如下图，线程组同级处有个固定吞吐量定时器，搜索3下有个固定定时器。 那每次跑搜索3时，延迟时间=固定定时器时间+固定吞吐量定时器的时间。 而每次跑搜索4时，延迟时间=固定定时器的时间

（4）  对于 和吞吐量相关的定时器（吞吐量定时器、固定吞吐量定时器），在设置吞吐量的值，首先要保证线程组中的线程数量是足够的，不然达不到吞吐量设置的要求。

下面将具体介绍每种定时器

1、 固定定时器

定时器用于延迟请求执行，固定定时器主要是固定了延迟的时间。

使用场景：1）一般接口测试时，接口文档中会明确说明此接口连续发送请求时，两个请求之间的间隔最低不能低于多长时间（这种可能一个请求执行完毕了，但后台姿源释放或者其他后台处理还没有执行完，所以要保证请求与请求之间要至少多大的间隔），那对此接口做性能测试、稳定性测试，就要加固定定时器。来保证请求之间的间隔要满足要求。2）模拟真是用户的使用场景，一般用户真正使平台时，对某个请求也不会连续不停的去请求，用户操作时会存在一定的思考时间，那这个思考时间就可以通过固定定时器来模拟。

固定定时器放在某个线程下，则此固定定时器，只对此线程起作用

若固定定时器放在某个线程组下，则此固定定时器对此线程组下的所有线程起作用（即每个请求模拟发送前，都要先固定等待N 秒）。

若固定定时器放在测试计划组件下，则此固定定时器，对测试计划下所有线程组下的所有线程起作用。

2、 synchronizing timer

同步定时器，主要是为了更准确的模拟同时并发执行的情况。

通常我们做并发测试时，是设置线程组中的线程数。如下图，当我线程数设置为10，ramp-up period 设置为1s 时，从结果中可以看到，每个请求的start time 还是有一点差距的。每个请求之间大概相差了100ms, 第一个请求和第十个请求相差了大概1s。 这是因为 线程数设置为10，ramp-up period 设置为1s的意思就是1s内把这10个请求模拟发送完。所以严格上讲这并没有达到真正意义上的同时并发请求。

为了能够模拟严格意义的并发，就需要使用synchronizing timer，当我在synchronizing timer设置为10 时，后台就会等到这10个线程都准备好了，再一起发送请求。如下图：

同步定时器的参数配置：

Number of simulated users to group by ：即设置要模拟多少用户去同时并发请求。此数值要小于等于线程组中的线程数。因为Number of simulated users to group by代表的是要集结多少个的时候才一起发送请求。 如果线程组中的线程数设置为5， 而Number of simulated users to group by设置为10 ，那将永远集结不到10个

 Timeout in milliseconds : 表示当超时多少毫秒后，还没有集结到Number of simulated users to group by中设置的数量的话。就不再等待，直接发送就可以了。如果此值为0的话，则会一直等待下去。

3、 constant throughput timer

吞吐量定时器。可以控制取样器发送请求的吞吐量，保证吞吐量在某个固定值下。固定吞吐量定时器组件的配置参数意思如下：

如下图，10线程下跑一个请求，跑一段时间后，可以看到吞吐量是308（单位是秒），那对应的一个线程的吞吐量是30，如果我想10个线程下，稳定在300的吞吐量一直跑下去的话，固定吞吐量定时器的target throughput 需设置为1800(即30个/s * 60 = 1800个/min), calculate throughput based on 设置为 this thread only,

从下图可以看到，添加并设置了固定吞吐量定时器后，吞吐量的值一下子就飙到了将近300， 但是存在两个疑惑点：1、为什么跑了一段时间，一直都没办法到达300的吞吐量呢？

2、为什么图形显示吞吐量的值，可以看到很不稳定啊

如果我想10个线程的情况下稳定跑300的吞吐量，其中calculate throughput based on 设置为 all active threads in current thread group, 那target throughput 需设置为18000.

当我把calculate throughput based on 设置为 all active threads,  target throughput设置为18000时，且有两个线程组，每个线程组下有一个https请求，两个线程组设置的线程数都是10 , 测试计划中【独立运行每隔线程组】选择去勾选。最后跑出来的结果如下

（总吞吐量18000个/min, 则平分到两个线程组的话是 9000个/min , 转化成秒的话是150个/min,所以跑出来的结果应该是150左右的吞吐量）

4、 jp@gc-throughput shaping timer

即吞吐量定时器，可以通过设置吞吐量定时器，来达到在某个时间段内，吞吐量是线性增长或稳定在某个值或线性下降的。

使用场景：通常使用此吞吐量定时器，来寻找请求的吞吐量的最大值（即找拐点）

如下图，是我添加了吞吐量定时器， 并对吞吐量定时器的设置：前50秒，吞吐量从0线性增长到200 ，50到110秒的时候，吞吐量从200线性增长到300， 110秒到290秒的时候，吞吐量固定在300一直跑， 290秒到350秒的时候，吞吐量从300线性下降到0， 最终跑出来的结果可以看到基本符合这个设定。

5、 uniform random timer

即统一随机定时器，和固定定时器差不多，只不过这个随机定时器，每次的延迟时间是随机的。

如下图，是执行结果

6、 bean shell timer

暂定，后续再讲