1、同步定时器 (Synchronizing Timer)
loadrunner称为集合点，SyncTimer的目的是阻塞线程，直到阻塞了n个线程，然后立即释放它们。 同步定时器相当于一个储蓄池，累积一定的请求，当在规定的时间内达到一定的线程数量，这些线程会在同一个时间点一起并发，所以可以用来做大数据量的并发请求。
添加方式：测试计划 --> 线程组--> HTTP请求 --> (右键添加) 定时器 --> Synchronizing Timer
注意：定时器一定要放在HTTP请求下，不要和HTTP同级。
有2个参数设置
- 模拟用户组的数量(Number of Simulated Users to Group by) 也就是并发数，集合多少请求后一起发出去
- 超时时间以毫秒为单位(Timeout in milliseconds) 指定人数多少秒没集合到算超时，默认为0，会一直等。设置500毫秒的话，如果500毫秒内凑齐并发数，就先发出去了。
案例：
新增线程组，设置线程数（用户数）为200，启动时间为10秒，那么200/10 = 20，就是每1秒钟就会增长20个用户数，需要10秒才能达到200的用户数
新增同步定时器，设置用户数为20，也就是当线程数达到20的时候，才会在同一时间并发发送请求。
如果最终人数不够20人，那么可以设置超时，我设置的是20秒，比如线程组用户数为200，设置定时器模拟人数为30，那么达到180的时候，最后线程组还可以模拟20个人，但是定时器需要30人，就会死锁，无线等待，因此设置超时释放是有必要的。
最后通过表格查看结果去查看是否在同一个时间内并发20个请求，如图所示，在一秒钟内，并发了20个请求，说明同步定时器设置成功。
2、吞吐量控制器(Constant Throughput Timer)
通过控制每分钟请求数（即控制吞吐的方式）来控制是否进行延时暂停。 例如，当我们需要使服务端长期处于一定的压力下时，可以通过该定时器来控制吞吐。
案例：
1、新建线程，用户数为1，启动时间为1，设置永久循环，不用户循环的话，无法持续进行稳定性测试
2、测试没有吞吐量定时器时，QPS为多少，如图可以看见，极限吞吐量大概在30左右。
3、设置吞吐量定时器，比如设置为每秒吞吐量为10，一个用户，吞吐量定时器是以每分钟来计算的，那么我们需要先计算一下。一分钟=60秒，每秒钟10qps /线程数1 X 60秒 = 600，那么需要设置目标吞吐量为600即可。
为什么要除以线程数1呢，因为--This thread only ：分别控制每个线程的吞吐量，选择这种模式时，总的吞吐量为设置的 target Throughput 乘以线程的数量。
五个选择项代表的意思：
this thread only：表示控制每个线程的吞吐量，选择这种模式 时，总的吞吐量为设置的目标吞吐量乘以线程的数量。
all active threads：表示设置的目标吞吐量将分配在每个活跃 线程上。每个活跃线程在上一次运行结束后等待合理的时间后 再次运行。活跃线程指某一时刻同时运行的线程。
all active threads in current thread group：表示设置的目标吞 吐量将分配在当前线程组的每一个活跃线程上，当测试计划中 只有一个线程组时，该选项和all active threads选项的效果完 全相同。
all active threads(shared)：与all active threads选项基本相 同，区别是每个活跃线程都会在所有活跃线程上一次运行结束 后等待合理的时间后再次运行。
all active threads in current thread group (shared)：与all active threads in current thread group选项基本相同，区别是 每个活跃线程都会在所有活跃线程的上一次运行结束后等待合 理的时间后再次运行。 
4、查看结果，可以看到，获取用户信息接口QPS成功限制在了10/sec
3、固定定时器
就是一个强制等待，到了时间再发送请求，放在HTTP请求下
