通过案例带你轻松玩转JMeter连载（59）

3定时器

3.1 常数吞吐量定时器 此计时器引入可变暂停，计算时使总吞吐量（以每分钟样本数为单位）尽可能接近给定的数字。当然，如果服务器无法处理吞吐量，或者如果其他计时器或耗时的测试元素阻止吞吐量，则吞吐量将降低。 注意：尽管计时器被称为常数吞吐量计时器，但吞吐量值不需要为常数。它可以通过变量或函数调用来定义，并且可以在测试期间更改值。可以通过以下方式更改该值。

• 使用计数器变量。
• 使用_jexl3、_groovy函数提供一个变化的值。
• 使用远程BeanShell服务器更改JMeter属性。

请注意，在测试期间不应频繁更改吞吐量值-新值，因为更改后需要一段时间才能生效。 通过右键在弹出菜单中选择“添加->定时器-> Constant Throughput Timer” ，如图9所示。

图9 常数吞吐量定时器

通过右键在弹出菜单中选择“添加->定时器-> Constant Throughput Timer” ，如图9所示。

• 目标吞吐量（每分钟的样本量）：希望计时器尝试生成吞吐量。
• 基于计算的吞吐量。

Ø 只有此线程：每个线程将尝试保持目标吞吐量。总吞吐量将与活动线程的数量成比例。 Ø 当前线程组中的所有活动线程：目标吞吐量分配给组中的所有活动线程。每个线程将根据需要延迟，具体取决于它上次运行的时间。 Ø 所有活动线程：目标吞吐量分配给所有线程组中的所有活动线程。每个线程将根据需要延迟，具体取决于它上次运行的时间。在这种情况下，每个其他线程组都需要具有相同设置的恒定吞吐量计时器。 Ø 当前线程组中的所有活动线程（共享）：如上所述，但每个线程都会根据组中任何线程上次运行的时间进行延迟。 Ø 所有活动线程（共享）：如上所述；每个线程都会根据任何线程上次运行的时间进行延迟。 共享和非共享算法都旨在生成所需的吞吐量，并将产生类似的结果。 共享算法应生成更准确的总体交易率。 非共享算法应该在线程之间生成更均匀的事务分布。

3.2 准确的吞吐量定时器 精确吞吐量计时器是一个计时器，使用户能够确定他们希望在测试中运行的吞吐量（每秒/分钟/小时采样器等）。与恒定吞吐量计时器相比，用户在决定如何随时间分布样本时更加灵活。此外，执行是以随机的方式安排的，从而能够建立恒定的负载。最后，该计时器使用泊松到达计划进行暂停，使其接近真实场景。 通过右键在弹出菜单中选择“添加->定时器-> Precise Throughput Timer”，如图10所示。

图10 准确的吞吐量定时器

• 目标吞吐量（每个“吞吐量周期”的样本数）：每个“吞吐量周期”（包括组中的所有线程）要从所有受影响的采样器获取的最大样本数。
• 吞吐量周期（秒）：吞吐量周期。例如，如果“吞吐量”设置为48，“吞吐量周期”设置为24秒，则每秒将获得2个样本。
• 测试持续时间（秒）：用于确保在“测试持续时间”时间段内获得吞吐量*持续时间样本。
• 批处理中的线程数（线程）：如果该值超过1，则多个线程同时离开计时器。平均吞吐量仍然满足“吞吐量”值。
• 批处理中线程之间的延迟（毫秒）：例如，如果设置为36，批处理大小为3，则线程将在x、x+36ms、x+72ms处离开。
• 随机种子（从0更改为随机）注意：不同的计时器最好具有不同的种子值。恒定种子确保计时器在每次测试启动时产生相同的延迟。值“0”表示计时器是真正随机的。