『动善时』JMeter基础 — 60、固定吞吐量测试
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（发送）：每秒发送到服务器端的数据量。
参考：
