计时器
Constant Timer
录制一个新的操作脚本，如下图所示。
执行测试后的结果显示如下。
从StartTime字段上看，第一次循环和第二次循环之间间隔了2秒，也就是16:18:03.173~16:18:05.115
为了避免两次循环之间由于访问太过频繁导致数据不一致，因此给Thread Group加入Timer。
添加的Constant Timer默认设置为300毫秒。
现在两次循环之间的间隔大约为5秒。
没加Constant Timer时，时间间隔是
2秒。现在有
11个请求（之间刚好有10个300毫秒的间隔），因此间隔时间就多了3秒。之前的间隔
2秒 + 现在延迟的3秒，正好是5秒。
Constant Throughput Timer
Constant Throughput Timer的名字虽然和Constant Timer类似，但其实并不一样。
Target throughput：表示目标吞吐量。例如，如果服务器每分钟能够处理100个请求，而这里仅设置为10，那么剩余的90个请求也必须等到下一分钟才能得到处理。反之，如果设置为200，那么服务器就不会有任何等待时间。Calculate throughput based on：计算吞吐量的方式。this thread only：这种模式下总的吞吐量=Target Throughput×线程数量。all active threads：Target throughput将分配在每个活跃的线程上，而活跃线程在上一次运行结束后等待合理的时间后再次运行。all active threads in current thread group：Target throughput将分配在当前线程组的每一个活跃线程上。如果整个测试计划只有一个Thread Group，那么该选项和前面的选项完全等效。all avtive threads（shared）：与all active threads基本相同。all active threads in current thread group（shared）：与all active threads in current thread group基本相同。
假设Constant Throughput Timer的设置如下。
由于1000远大目前的系统吞吐量，所以应该执行后应该没有明显的时间延迟，效果应该和之前执行Constant Timer一致。
从上图显示的执行结果来看，确实如预料的那样，两次循环之间的时间间隔大约为2秒，和Constant Timer一致。
现在，如果将Target throughput改为10，很明显这要低于系统的吞吐量，那么预期延迟会比现在要长。
这次的时间间隔已经达到6秒，明显要大于2秒。
Gaussian Random Timer
删除之前的计时器，添加Gaussian Random Timer。
执行测试后的结果显示如下。
现在的时间间隔既不是2秒，也不是6秒，而是介于4~5秒之间了。
感谢支持
更多内容，请移步《超级个体》。