常用逻辑控制器和定时器

• 一、认识逻辑控制器
• • 一、作用：⼀个事务会包含并请求
  • 二、常见逻辑控制器介绍
  • • 1、simple controller
    • 2、recorder controller
    • 3、loop controller
    • 4、random controller
    • 5、if controller
    • 6、module/include controller
    • 7、transaction controller
• 三、Jmeter定时器
• • 一、作用：
  • 二、常用定时器
  • • 1、固定定时器（Constant Timer）
    • 2、高斯随机定时器（Gaussian Random Timer）
    • 3、常数吞吐量定时器（Constant Throughput Timer）

一、认识逻辑控制器

一、作用：⼀个事务会包含并请求

二、常见逻辑控制器介绍

1、simple controller

作用：把一系列请求聚合在一起，方便进行管理

2、recorder controller

作用：把录制的请求存放在下面

3、loop controller

作用：指定其子节点运行的次数，可以使⽤具体的数值，也可以使用变量

• 1、Forever选项：表示⼀直循环下去
• 2、如果同时设置了线程组的循环次数和循环控制器的循环次数，那循环控制器的⼦节点运⾏的次数为两个数值相乘的结果
  
  例子：这里添加了loop controller，然后在里面设置百度跑5次，然后知乎在控制器外，只设置1次，所以这里百度跑5次，知乎跑1次
  

4、random controller

作用：随机执行其下的某个子结点Demo
例子：这里随机控制器里面有3个，每次都随机执行其中任意一个

5、if controller

作用：某个判断
例子：上一个请求成功才能执行下一个请求（可以做条件判断，避免写入脏数据，在一些简单场景下可以替代后置处理器，做简单的逻辑判断）

• 首先我们在上面添加谷歌的sample（访问不了，肯定会失败）
• 然后我们在if逻辑控制器里添加这个条件
  ps：JMeterThread.last_sample_ok 这个参数表示接口是否请求成功，返回true或者false
  
• 最后我们在if控制器里面添加百度的sample，然后运行，这里发现因为Google访问失败，故访问百度没有执行
  

6、module/include controller

作用：

• module controller：把其他模块module当做自己的下属模块复用
• include controller：把其他test plan引用进来当做一个完整的处理逻辑使用
  

7、transaction controller

作用：一个事务会包含并请求
讲这个之前，我们需要先了解TPS和QPS

• QPS：每秒钟处理完请求的次数：注意这里是处理完。具体是指发出请求到服务器处理完成返回成功结果。可以理解有个counter，每处理一个请求+1,1s后counter=QPS
• TPS：每秒钟处理完的事务次数，一般TPS是对整个系统来讲的。一个应用系统1s能完成多少事务处理，一个事务在分布式处理中，可能会对应多个请求，对于衡量单个接口服务的处理能力，用QPS比较多
• 如果一个事务只包含一个请求，那他们的数据是一致的，如果一个事务有多个请求相互关联，那他们的内容就会不同，我们关注的一般是事务而不是请求的耗时，这个时候我们就可以添加事务控制器了
  例子：这里可以看到事务会把两个的结果相加
  

三、Jmeter定时器

一、作用：

实际操作中，模拟真实⽤户在操作过程中的等待时间

二、常用定时器

1、固定定时器（Constant Timer）

设置固定时间，比如我们设置每隔3s执行一次

2、高斯随机定时器（Gaussian Random Timer）

设置随机时间执行

• Deviations (milliseconds) ⾼斯定时器参数，从100毫秒里随机选择一个作为高斯分布的时间点
• Constant Delay Offset (milliseconds) 固定等待时⻓，也是毫秒为单位
• 两者加在一起就是总的延迟时长
• 这个功能互联网行业不太用到，因为互联网行业认为用户是无时无刻都会来访问的，传统行业用的较多

3、常数吞吐量定时器（Constant Throughput Timer）

常用，重点掌握！

• 产生背景：线程组无法控制TPS,QPS，只能控制线程数（并发用户数），如我想用100线程并发模拟1000QPS的任务，但是实际操作有时候会超过1000QPS，导致服务挂掉，这个时候我们就需要用到吞吐量定时器
• Target throughput（in samples per minute）：目标吞吐量。注意这里是每分钟发送的请求数，因此，对应测试需求中所要求的20 QPS ，这⾥的值应该是1200 。
• Calculate Throughput based on：有5个选项，分别是：
  • 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 cative threads in current thread group （shared ）：与All active threads in current thread group 基本相同，唯⼀的区别是，每个活跃线程都会在所有活跃线程的上⼀次运

例子：
比如有个订单的线程组，我们设置20个并发用户同时下单，吞吐量设置为1200

100个用户浏览门店商品，吞吐量设置为6000


我们可以通过配置线程数和吞吐量等方式来控制事务的QPS

小TIPS：
如果希望在 sampler 执⾏完之后再等待，则可以使⽤Test Action，5.0 叫 Flow Control Action（sampler-flow control action）