目录
JMeter（一）：基础概念
JMeter（二）：配置元件
JMeter（三）：变量参数化
JMeter（四）：监听器
JMeter（五）：脚本录制
JMeter（六）：断言
Jmeter（七）：逻辑控制器
定时器（间隔时间/思考时间）
在默认情况下，jmeter发送每个请求之间是没有延时的，如果线程数足够大，瞬间就会将服务器压死。
在实际的业务过程中，请求之间是有一定时间的停顿的，比如登录网站时输入用户名和密码需要时间（用户会确认下输入的对不对），所以在请求之间设置合理的延时是必须的，也更接近用户的真实业务情况。
在jmeter中，定时器组件提供了系列不同类型的延时控制。合理使用定时器组件，能让你的性能测试更接近真实，更能挖掘出系统的瓶颈和评估系统的性能指标。
基本规则：在每个sampler之前去执行
一、固定定时器
场景应用：性能测试中，根据用户操作预估时间
PS：在实际模拟用户请求的过程中，会失去灵活性，不推荐大量使用
如图登录请求已延时3秒启动
二、高斯随机定时器
也称作正态分布随机定时器，可以设置在两个请求间随机延时时长，在使用时须指定偏差延时值和偏移值
线程的等待时间：在偏差——(偏差+固定延迟偏移)内随机取值
实际情况中，受网络、人等各种因素影响，访问同一个页面响应时间也会不一样，使用该定时器模拟操作，更接近用户实际情况
如图，设置了4个线程数
三、Synchronizing Timer
同步定时器，Jmeter集合点是通过这个定时器来实现的，也就是人为并发
PS：集合点用于同步虚拟用户恰好在某一时刻执行任务，确保用户更准确、集中的进行某个指定操作，达到更理想的负载模拟效果，更有针对性地对某个可能存在性能问题的模糊或子系统施压，以便找到性能瓶颈。
比如100个人在跑1千米，组办方在500米处设有栅栏，需要等大家都到了才移开
参数说明
- Number of Simulated Users to Group by：每次释放的线程数量
- 设置为0，等同于设置为线程租中的线程数量
- 设置为10，表示等待10个用户到达后，再一起并发请求
- Timeout in milliseconds：默认为0
- 设置为0，Timer将会等待线程数达到了"Number of Simultaneous Users to Group"中设置的值才释放。
- 大于0，那么如果超过Timeout in milliseconds中设置的最大等待时间(毫秒为单位)后还没达到"Number of Simultaneous Users to Group"中设置的值，Timer将不再等待，释放已到达的线程。
注意：
如果设置Timeout in milliseconds为0，且线程数量无法达到"Number of Simultaneous Users to Group by"中设置的值，那么Test将无限等待，除非手动终止。
如上图：
（1）在等待时间之前10个线程全部到达，那就全部释放
比如10个用户同时提交订单，当虚拟用户没有达到10个时，通过此设置可以让用户暂停下来，处于等待状态，当10个全部到达后提交订单
PS：集合点也是相对的，即使进行了设置，假设1000个用户提交订单也无法在几毫秒内完成，可能需要几十毫秒甚至几百毫秒完成。但不进行设置，1000个用户提交订单可能在几秒甚至几十秒才完成
（2）超过1000毫秒之后释放线程数：假如9个线程已经到达，还有一个未到达，时间到达1000毫秒后就不管未到达的线程了，直接进入下一步的并发
场景应用：0点秒杀
四、Uniform Random Timer
在请求之间设置随机延时，每个随机延时有相同的发生概率。总的延时等于随机延时 + 偏移延时值。
如图，总延时=random(0,200)+100，取值在100至300之间，跟高斯随机定时器有一点区别
五、Poisson Random Timer
类似高斯随机定时器，只是其随机延时值发生在一个特定的值，总的延时值呈现泊松分布。
六、Constant Throughput Timer
通过控制每分钟请求数（即控制吞吐的方式）来控制是否进行延时暂停。
例如，当我们需要使服务端长期处于一定的压力下时，可以通过该定时器来控制吞吐。
PS：吞吐值可以是常量，也可以使用函数来动态生成，满足不同的压力场景
