about

在默认情况下，jmeter发送每个请求的间隔极短，如果线程数足够大，瞬间就会将服务器压死。
在实际的业务过程中，请求之间是有一定时间的停顿的，比如登录网站时输入用户名和密码需要时间（用户会确认下输入的对不对），所以在请求之间设置合理的延时是必须的，也更接近用户的真实业务情况。

在jmeter中，定时器组件提供了系列不同类型的延时控制。合理使用定时器组件，能让你的性能测试更接近真实，更能挖掘出系统的瓶颈和评估系统的性能指标。

基本规则：在每个采样器（sampler）之前去执行，也就是定时器的作用域：

定时器是在每个采样器（sampler）之前执行的，而不是之后（无论定时器位置在采样器（sampler）之前还是下面）。
当执行一个采样器（sampler）之前时，所有当前作用域内的定时器都会被执行。
如果希望定时器仅应用于其中一个采样器（sampler），则把定时器作为子节点加入。

截止到目前，jmeter共提供了如下几种定时器，以适应更多的场景：

我们来看看常用的定时器的用法。

固定定时器

固定定时器，应用场景，登录，比如用户在输入完密码之后，会思考一下用户密码是否输入有误，然后再点击登录，那么这个固定定时器，就可以等2秒再去执行，那也因此有些问题，这个固定的时间相对比较死板。

http://www.neeo.cc:6001/get?user=zhangkai&pwd=666  # get

在线程组内新建一个"HTTP请求"取样器，并为该取样器添加一个"固定定时器"：

"固定定时器"的配置：

结果，没啥好看的：

同步定时器

场景应用：0点秒杀

"同步定时器"，jmeter集合点是通过这个定时器来实现的，也就是人为并发。

PS：集合点用于同步虚拟用户恰好在某一时刻执行任务，确保用户更准确、集中的进行某个指定操作，达到更理想的负载模拟效果，更有针对性地对某个可能存在性能问题的模糊或子系统施压，以便找到性能瓶颈。

简单来说，集合点的概念，相当于我们10个人约好明天上午9点一起去逛街，那么到明天上午九点，会有如下几种情况：

10个人在9点之前就凑齐了，走吗？不走！要等9点再走！
9点了，10个人才到了8个，那还等剩下的两个人吗？可以选择等，如果永远凑不够10个，就一直等；还有一种情况就是，不等剩下的两个人了，直接到点就走，有几个人走几个人。

"同步定时器"通过不同的参数也能完成不同的场景，所以，它在做性能测试的时候，模拟的更准确。

首先，在线程组内添加一个"HTTP请求"取样器：

再为"HTTP请求"取样器添加一个"同步定时器":

接下来，我们来研究同步定时器各个参数组合情况，都有哪些不同的结果产生。

"同步定时器"的模拟用户组的数量参数，有以下几种情况：

等待所有的虚拟用户(线程)后，一次性发送所有的请求，示例：
- 线程组的线程数：5；
- 同步定时器的模拟用户组的数量：10；
- 同步定时器的超时时间以毫秒为单位：0；
- 结果是，jmeter会一直等凑够10个用户，但很明显，因为线程数为5，它永远也凑不够10个用户，而且也没设置超时时间，所以，jmeter就一直在等在凑够10个用户.....
如果设置为0，等同于设置为线程组中线程数的值，示例：
- 线程组的线程数：5；
- 同步定时器的模拟用户组的数量：0；
- 同步定时器的超时时间以毫秒为单位：1000；
- 结果是，如果在规定的超时时间内，凑够了5个用户，然后会一次性的发送5个请求；如果在规定的超时时间内，没有凑够5个用户，比如只凑够了3个，那么当超时时间结束后，会发送3个请求；如果没有设置超时时间，jmeter会在1000毫秒内发送5个请求。
如果设置的值不大于它所在线程组的线程数，jmeter会轮询的在超时时间结束发送指定的用户数，示例：
- 线程组的线程数：5；
- 同步定时器的模拟用户组的数量：4；
- 同步定时器的超时时间以毫秒为单位：2000；
- 结果是，如果在没达到超时时间时，哪怕jmeter凑够了4个用户，它也不发送请求，而是要等超时时间结束再一次性的发送所有的请求；问题来了，我们线程数时5个，此时发送了4个请求，还剩下1个用户每发送呢？怎么办？jmeter会在下一次超时时间结束在发送剩下的1个请求；如果线程数还没使用完，就继续在下一次轮询发送，你可以将线程数设置5，同步定时器的模拟用户数设置为2，超时为2000毫秒，再运行会发现，每2000毫秒发送2个用户，最后一轮会发送1个用户。