目录
使用【定时器】的主要目的是模拟用户的“思考时间”，在负载测试领域，“思考时间”代表模拟真实用户行为，就是人们在与web应用程序的交互等待时间。
定时器会在每个取样器运行之前执行，如果有多个定时器，则在采样器执行之前将运行所有定时器。
根据Jmeter5.0版本，可以使用以下Timer测试元素：
- 固定定时器（Constant Timer）
- 统一随机定时器（Uniform Random Timer）
- 高斯随机定时器（Gaussian Random Timer）
- 泊松随机定时器（Poisson Random Timer）
- 精准吞吐量定时器（Precise Throughput Timer）
- 固定吞吐量定时器（Constant Throughput Timer）
- 同步定时器（Synchronizing Timer）
- BeanShell定时器（Beanshell Timer）
- JSR223定时器（JSR223 Timer）
个人认为，固定定时器和统一随机定时器，足以覆盖90%的测试情况，并建议大家在脚本中使用它们。但是，如果你的思考时间模拟要求基于更复杂的数学和统计分布，那么当然你要了解其他的定时器。
如果要让每个线程在请求之间暂停相同的时间，请使用此计时器。
需要注意的是：固定计时器的延时不会计入单个sampler,但会计入事务控制器的时间，如果在事务控制器内使用，则要注意。
统一随机定时器将线程暂停一个系数：
- 下一个伪随机均匀分布的值，范围在0.0(含)和1.0(不包括)之间
- 乘以“随机延迟最大值”
- 加上“恒定延迟偏移”
它会将采样器暂停一个随机数毫秒，范围从0到99，公式：0.X * 100 + 0 ，其中X可以是0到9之间的数字。如果恒定延迟偏移为10，则0.X * 100 + 10。
【模拟用户组的数量（Number of Simulated users to Group by）】：集合点集合够N个用户释放线程，最后一批线程数不够集合点数目时，Jmeter会停止不动，如果碰到这种情况，就只能杀掉Jmeter进程重新执行测试。
比如：线程6个，集合点设置5个。【超时时间（Timeout in milliseconds）】设置为0，最后一个用户则达不到5个就会一直等。
【超时时间（Timeout in milliseconds）】：如果设置为0，则定时器会一直等待线程数达到【模拟用户的数量】设置的值，如果大于0，则定时器将以此值为最大“超时取等待线程数” 。如果在超时间隔后未达到等待的用户数，则计时器将停止等待。
该计时器自行暂停，计算来达到总吞吐量尽可能的接近给定的数字，当然，如果服务器本身有瓶颈，或者其他耗时的测试元件阻碍了它，吞吐量仍然不可避免的会降低。
吞吐量计算的范围可以为指定为当前线程、当前线程组、所有线程组，并且计算吞吐量的依据可以是最近一次线程的执行时延。
参数解读：
1）目标吞吐量：每分钟的吞吐量
2）基于的计算吞吐量：有5个选项：
- 只有此线程：控制每个线程的吞吐量，选择这种模式时，总的吞吐量为设置的 目标吞吐量 乘以该线程的数量
- 所有活动线程：设置的 目标吞吐量 将分配在每个活跃线程上，每个活跃线程在上一次运行结束后等待合理的时间后再次运行。活跃线程指同一时刻同时运行的线程。
- 所有活动线程(共享)：与 所有活动线程 的选项基本相同。唯一区别是，每个活跃线程都会在所有活跃线程上一次运行结束后等待合理的时间后再次运行。
- 当前线程组中的所有活动线程：设置的 目标吞吐量 将分配在当前线程组的每一个活跃线程上，当测试计划中只有一个线程组时，该选项和 所有活动线程 选项的效果完全相同。
- 当前线程组中的所有活动线程(共享)：与 当前线程组中的所有活动线程 基本相同，唯一的区别是，每个活跃线程都会在所有活跃线程的上一次运行结束后等待合理的时间后再次运行。
固定吞吐量定时器说明：
一般情况，请求之间始终存在间隔，网络中总会出现一些短暂（毫秒类型）延迟，作为用户，我们仍然需要一些时间来思考和点击链接。这也是我们性能测试过程中需要重现实际用户行为的原因。
我们有固定数量的用户，可以管理用户数每分钟不同数量的请求来测试应用程序，但不能管理请求的频率。这个时候就需要【固定吞吐量计时器】
该定时器允许我们保持总吞吐量不变，当然，如果服务器无法处理这样的负载，吞吐量会降低。虽然Timer被称为【固定吞吐量定时器】，但吞吐量值不需要一定是常量。在测试期间可以更改此值（计数器，Beanshell，JavaScript等函数提供不断变化的值）。
固定吞吐量计时器可以放在测试计划的根元素中。尽量不要使用多个吞吐量恒定时器，因为这可能会导致不同线程组中的请求之间的延迟混淆。
恒定吞吐量计时器只能暂停 JMeter线程以减慢它们以达到目标吞吐量，所以要确保有足够的线程来保证每秒所需的请求数量。另外，固定吞吐量计时器仅在分钟级别上才会足够精确，所以需要正确计算加速期并让我们的测试运行足够时间长。
参数设定：
1、若TPS有预期值，
设置定时器Throughput的值（与TPS接近），线程数随机设置一个比较小的值，开始启动压测，观察error比例（如果很小，符合要求，否则需要减小线程数），观察time，如果time大于线程数/TPS，则需要适当增加线程数，直至time大约等于线程数/TPS；此时如果error很小，则说明接口可以承受预期压力；
2、若TPS没有预期值
a) 设置定时器Throughput的值，线程数依次增加（比如先设置100，再200，再500，再1000），按照不同的线程数分别压测，当error比例开始明显增加，停止压测，记录此时线程数x。
b) 再次修改线程数进行压测，此次线程数的值不要超过x，等比例增加线程数（比如100，再200，再300....），按照不同的线程数分别压测，并记录不同线程数下的time，分别算得不同线程数下的TPS（TPS整体趋势应该是先增长后下降，有一个大致的峰值），找到最大的TPS的值，即得到接口最大的TPS。
建议：
1.建议定时器添加在线程组最后一个请求下；
2.建议选择当前线程组中的所有活动线程；
3.当目标吞吐量设置为你，模式选择当前线程组中的所有活动线程 ，若固定吞吐量控制器放在，代表该请求的tpm为你，若放在事务控制器下，且事务控制器下的请求有3个，那么每个请求的tpm为n/3
理解可参考：
