目录

五、性能脚本完善以及增强

1. 常用逻辑控制器

1. 事务控制器

2. 仅一次控制器

3. 吞吐量控制器

2. 定时器（少用）

1. 固定定时器

2. 统一随机定时器

3. 高斯随机定时器

3. 集合点

4. 线程组：简单压一压

六、Jmeter的插件安装以及监控使用

1. 使用步骤

2. TPS和RT直接增加就可以

3. 如果想监听服务器性能：CPU、内存

七、实际性能压测场景设置

1. 场景

2. 单接口

3. 混合负载压测场景

4. 压力测试场景

5. 稳定性测试场景。

---

五、性能脚本完善以及增强

1. 常用逻辑控制器

• 事务控制器

• 仅一次控制器：一般用于控制登录

• 吞吐量控制器

1. 事务控制器

• 线程组-》添加-》逻辑控制器-》事务控制器-》把7.点击发帖 和 8. 发帖 两个拖动到事务控制器里-》命名为【发帖事务】
  

• 事务控制器-》勾选generate parent sample

  • 勾选前

  • 勾选后

2. 仅一次控制器

• 线程组-》添加-》逻辑控制器-》仅一次控制器-》把3. 登录接口拖动到仅一次控制器里

  • 线程组-》线程数填写为10 循环次数填写为10

3. 吞吐量控制器

• 线程组-》添加-》逻辑控制器-》吞吐量控制器-》把9. 回帖拖动到吞吐量控制器里

  • 线程组-》线程数填写为10 循环次数填写为10

  • 吞吐量控制器

    • base on：（1） Percent Executions(默认) 按百分比分配流量 （2） Total Executions 按总次数分配

    • 吞吐量：（1） 20.0 （2） 50

2. 定时器（少用）

• 固定定时器

• 统一随机定时器

• 高斯随机定时器

1. 固定定时器

• 三秒之内只能回帖一次

  • 线程组-》9. 回帖-》添加定时器-》固定定时器-》线程延迟（毫秒）填3000

2. 统一随机定时器

• 线程组-》9. 回帖-》添加定时器-》统一随机定时器-》

  • Random Delay Maximum(in milliseconds)（表示随机时间）：填5000

  • ConstantDelay Offset (in milliseconds)（表示固定时间）：填3000

  • 也就是说时间是3-8s随机

3. 高斯随机定时器

• 线程组-》9. 回帖-》添加定时器-》高斯随机定时器-》

  • 偏差(毫秒)：1000

  • 固定延迟偏移(毫秒)：3000

  • 时间是2-4s

3. 集合点

• jmeter叫同步定时器。用于实现并发。

• 线程组-》添加-》定时器-》Synchronizing Timer-》把它挪到上面-》命名为【同步定时器-集合点】

  • 模拟用户组的数量 50

  • 超时时间以毫秒为单位 60000

  • 达到50用户即开始并发/达到超时6分钟即开始并发（发送请求）

• 线程组-》

  • 线程数 100

  • ramp-up时间 20 （10s加载100个）

  • 循环次数 3

4. 线程组：简单压一压

• 用法一：

  • 线程数：虚拟用户数100

  • ramp-up：多久加载完虚拟用户数 20 （20s加载100个）

  • 循环次数：3

    • 每个线程发送的次数：100*3=300个

• 用法二：

  • 循环次数永远 + 调度器持续时间设置

六、Jmeter的插件安装以及监控使用

• 监控图的作用主要是:

  • 看趋势，找性能拐点

  • 写性能测试报告

1. 使用步骤

1. 下载插件管理包jmeter-plugis-manager版本.jar包，放到jmeter的lib/ext目录下

2. 重启jmeter，可以看到右上角有一个小红色图标，就有了插件管理。

3. 安装jmeterplugins-extras.jar和jmeterplugins-standard.jar

2. TPS和RT直接增加就可以

• 线程组-》添加-》监听器-》jp@gc-Transactions per Second(聚合报告中的吞吐量)

• 线程组-》添加-》监听器-》jp@gc-Respose Times Over Time(聚合报告中的平均值)

3. 如果想监听服务器性能：CPU、内存

• 线程组-》添加-》监听器-》jp@gc-PerfMon Metrics Collector(聚合报告中的吞吐量)

  1. 需要在服务器安装一个ServerAgent.zip，用于收集服务器的性能参数。然后通过4444端口输出。

  2. 在PerfMon Metrics Collector组件中通过4444端口去捕获服务器性能参数。

• linux服务器中

  1. cd到所要上传ServerAgent.zip的路径下

  2. rz命令上传包，上传完成后可以用ls命令检查是否上传成功

  3. 当前路径 创建文件夹mkdir ServerAgent

  4. 进行解压unzip ServerAgent.zip -d ServerAgent

  5. cd ServerAgent，就是如下内容

  6. 给权限chomd 777 startAgent.sh

  7. 启动服务./startAgent.sh &，出现如下即成功

  8. 关闭防火墙systemctl stop firewalld.service

  9. 在jmeter中jp@gc-PerfMon Metrics Collector组件下配置-》host : 192.168.0.100 port:444 CPU

七、实际性能压测场景设置

1. 场景

• 场景：性能测试用例

  • 旧系统来自于运维

  • 新系统来自于合理预估

    • 按场景和规则预估：做OA，总用户10000个，测试打卡功能做并发，8.30-9/00般大部分的公司很难超过500。5000以上，1万，十万，百万一定要集群

    • 服务器（集群）和压力机（集群）

2. 单接口

• 单接口基准测试：使用一个用户测试接口5分钟

  • 目的：为了在没有任何压力的情况下，查看各项性能指标

• 单接口负载测试场景：

  • 通过逐渐的对一个接口进行施压直到出现性能拐点。 获得被测接口的最大处理能力和能达到的性能指标。

3. 混合负载压测场景

• 不是只有一个场景，有多个

• 混合负载压测场景：

  • 目的：为了验证整个业务的最大的最优的性能体现。

  • 重点在于模型的设计，模型来在生成环境的日志或者产品经理给出的。

• 步骤：

  1. 测试计划-》添加-》线程-》jp@gc-Stepping Thread Group，jp@gc -Ultimate Thread Group

     • 递增式线程组（用的最多）jp@gc-Stepping Thread Group

     • 极限线程组jp@gc -Ultimate Thread Group

  2. 把所有的测试 都剪切到jp@gc-Stepping Thread Group这个下面

  3. 设置压测策略/场景/用例

     • This group will start 启动多少线程，100

     • First wait for 等待多少秒开始压测，一般为0

     • Then start 一开始有多少个线程数，一般为0

     • ---

       Next, add 10 启动多少个虚拟用户数

     • threads every 30 每组数据持续运行多少秒

     • using ramp-up 5 表示每多少秒

       • 表示每多少秒启动多少个虚拟用户数，每组数据持续运行多少秒

     • ---

       Then hold load for （如果做压力测试一般是4，8，12，24） 全部加载完成后，负载运行多少秒

       ---

     • Finally, stop 5 停止5个虚拟用户数

     • threads every 1 每1秒停止

       • 表示每1秒停止5个虚拟用户数

4. 压力测试场景

• 验证系统的极限，直到有任何一个性能指标超出预期

5. 稳定性测试场景。

• 在压力测试的场景下持续的运行4-24个小时