『动善时』JMeter基础 — 60、固定吞吐量测试

1、定时器介绍
2、固定吞吐量定时器介绍
3、固定吞吐量定时器界面说明
4、固定吞吐量定时器的使用

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