1、定时器介绍

默认情况下，JMeter线程发送请求之间是没有间歇的。建议为线程组添加某种定时器，以便设定请求之间的间隔是多长时间。如果测试人员不设定这种延迟，JMeter可能会在短时间内产生大量的并发访问请求，导致服务器宕机。

定时器会让作用域内的每一个取样器，都在执行前等待一个固定时长。定时器可以作为取样器或者逻辑控制器的子项，目的是只影响作用域内的取样器。

如果测试人员为线程组添加了多个定时器，那么JMeter会将这些定时器的时长叠加起来，共同影响作用域范围内的取样器。

2、固定吞吐量定时器介绍

一般我们进行压力测试时，会通过测试获取QPS（TPS）值，来判断系统的性能。

但有时为了复现线上生产的问题，需要尽可能还原生产场景，这时就可以通过设置固定的QPS（TPS）值，复现和线上生产过程相同的压测。

那么如何实现此要求呢？

可通 过固定吞吐量定时器 （ Constant Throughput Timer ）组件来实现。

该定时器引入了变量暂停，通过计算使得总吞吐量（以每分钟去计算）尽可能接近给定的数字。当然，如果服务器不能处理它，或者如果有其他定时器或耗时的测试原件阻止它，那么吞吐量将更低。

虽然该计时器被称为常数吞吐量定时器，但吞吐量值并不一定是常数。它可以根据变量或函数调用定义，并且可以在测试期间改变该值。

通过以下多种方式都可以改变：

使用计数器变量。

使用一个 __jexl3 或者 __groovy 函数，来提供一个变化的值。

使用远程BeeShell脚本更改JMeter属性。

3、固定吞吐量定时器界面说明

添加 固定吞吐量定时器 组件操作： 选中“取样器”右键 —> 添加 —> 定时器 —> 固定吞吐量定时器 。

界面如下图所示：

下面是 固定吞吐量定时器 组件的详细说明：

名称 ： 固定吞吐量定时器 组件的自定义名称，见名知意最好。

注释 ：即添加一些备注信息，对该 固定吞吐量定时器 组件的简短说明，以便后期回顾时查看。

Delay before each affected sampler ：设置每个受影响采样器的延迟。

Target throughput (in samples per minute) ：设置每分钟的目标吞吐量（以每分钟样本为单位）
注意这里的时间是分钟，不是 per second （秒），
即：测试在 20 QPS 情况下的系统表现，那么这里我们应该填 20*60=1200。

Calculate Throughput based on ：以下面哪个选项为基础，来计算吞吐量。

this thread only ：控制每个线程的吞吐量。
选择这种模式时， 总的吞吐量= Target throughput * 该线程的数量 。

all active threads ：设置的 Target throughput 将分配到所有线程组的所有活动线程上，每个活跃线程在上一次运行结束后，等待合理的时间后再次运行。（活跃线程指同一时刻同时运行的线程）
在这种情况下，每个线程组需要一个具有相同设置的固定吞吐量定时器。

all active threads in current thread group ：设置的 Target throughput 将分配在当前线程组的每一个活跃线程上，每个线程将根据上次运行时间延迟。当测试计划中只有一个线程组时，该选项和 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、固定吞吐量定时器的使用

需求说明 ：模拟一个用户组以20QPS的频率来访问服务器，持续10秒钟，查看服务器平均响应时间。

（1）测试计划内包含的元件

添加元件操作步骤 ：

创建测试计划。

创建线程组： 选中“测试计划”右键 —> 添加 —> 线程（用户） —> 线程组 。

在线程组下，添加取样器“HTTP请求”组件： 选中“线程组”右键 —> 添加 —> 取样器 —> HTTP请求 。

在取样器下，添加定时器“固定吞吐量定时器”组件： 选中“取样器”右键 —> 添加 —> 定时器 —> 固定吞吐量定时器 。

在线程组下，添加监听器“聚合报告”组件： 选中“线程组”右键 —> 添加 —> 监听器 —> 聚合报告 。

最终测试计划中的元件如下：

点击运行按钮，会提示你先保存该脚本，脚本保存完成后会直接自动运行该脚本。

（2）登陆请求内容

标准的POST请求，添加请求的基本要素，和所需要的数据即可。

如下图所示：

（3）固定吞吐量定时器内容

固定吞吐量定时器配置内容：

设置每分钟的目标吞吐量：因为我们是模拟20QPS情况下的系统表现，那么这里我们应该填 20*60=1200。
提示：60表示一分钟有60秒。

选择哪些线程组，来计算吞吐量：就选择 this thread only 就可以。

编辑完成的内容如下：

（4）线程组元件内容

前面只是配置了单位时间的目标吞吐量，下面我们要接着配置JMeter持续发送请求的时间。

在线程组元件中的配置如下：

在线程属性的循环次数，勾选上“永远”，（此时旁边的 editText 就无法输入了）。

勾选“调度器”，在持续时间中配置10秒，或在启动时间、结束时间处配置一个时间间隔为10秒的时间区间。

如下图所示：

当然我们也可以进行估算，来设置循环次数。

设置循环次数= 访问频率（QPS） * 持续时间，即：20 * 10 = 200。

（5）查看聚合报告的结果

运行脚本，结果如下：

我们可以从上图中看到， Throughput 的值为20QPS，证明测试复现了线上的压力环境，然后去查看其他的监听数据是否有异常。（每次 Throughput 的值会有稍微的浮动）

聚合报告参数介绍：

Label ：请求的名称，就是脚本中 Sampler 的名称。

# Samples （样本）：总共发给服务器的请求数量，如果模拟10个用户，每个用户迭代10次，那么总的请求数为：10*10 =100次。

Average （平均值）：默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller （事务控制器） 时，也可以用 Transaction 的时间，来显示平均响应时间 ，单位是毫秒。

Median （中位数）：50%用户的响应时间小于该值。

90% Line （90% 百分位）：90%用户的响应时间小于该值。

95% Line （95% 百分位）：95%用户的响应时间小于该值。

99% Line （99% 百分位）：99%用户的响应时间小于该值。

Min （最小值）：最小的响应时间。

Maximum （最大值）：最大的响应时间。

Error% （异常%）：错误率=错误请求的数量/请求的总数。

Throughput （吞吐量）：默认情况下表示每秒完成的请求数（ Request per Second ）。

Received KB/sec （接收数据）：每秒从服务器端接收到的数据量。

Sent KB/sec （发送）：每秒发送到服务器端的数据量。

https://www.it610.com/article/1277228378268647424.htm

https://blog.csdn.net/shuimengzhen/article/details/57075437