性能场景设计

6种常见设计方法：

• 普通性能场景设计
• 阶梯性能场景(负载测试场景)
• 压力测试场景
• 面向目标场景（lr很容易，但是jmeter，没有系统讲解，不知道怎么做）
• 混合场景设计（混合，if条件）不同数量的人，向不同的接口发起请求
• 有时间规律场景

  一、普通性能场景设计

1、基础知识

• 线程数：jmeter本身对线程数没有限制,但是jmeter钱这些并发用户数的时候，需要消耗资源，收到 电脑spu的主频限制，一条电脑不可能无限制的启动线程数，实际情况下，http协议大概可以产生1500左右，保守一点是1000左右，如果要模拟超过1000的并发线程数，可能需要考虑分布式。
• ramp-up：启动所有线程数的时间，500以内的并发用户，ramp-up  大概是2-3秒；500-1000 ramp-up大概是5秒；大于1000  ramp-up大概是5-8秒；一个原则：ramp-up时间在总的执行时间中占比要很低。
• 循环次数：就是每个并发用户数要去执行的请求数量，默认必须大于1。
• 复习框：永远，一直循环，直到你点击停止，才会停止。这个停止会有问题吗？ 会有问题，会导致请求报错，或卡死
• 永远应该怎么用呢？ 要与调度器一起使用必须把两个勾都勾选
• 调度器：
  • 持续时长
  • 启动延迟

2、应用场景

30个并发用户，持续运行300s，没有网络瓶颈，所以聚合报告中的吞吐量等于tps

聚合报告： avgRT： 1.364s     90%RT：1.63s      avgTPS： 21.9    

结论：

• 90%RT：1.63s  可以看到，这个响应时间是比较长，已经超过了我们用户能容忍的范围了，用户满意度指数1.5s，说明我们的接口响应比较慢。
• 30个人， avgTPS： 21.9    tps<user（吞吐量21.9小于用户数30）  那么，每个人1秒钟发不了1个请求，所以，我们次数 30个并发用户数，已经超过了我们项目这个接口能承受最大并发用户数了。
• 可以简单得到一个结论： 服务器注册接口最大并发用户数小于30的

二、阶梯性能场景(负载测试场景)===》最大并发用户数

1、应用场景1：如果接口从来没有做过性能测试，不知道一些指标信息，可以使用负载场景测试逐渐增加并发用户数来找出性能瓶颈。逐步增加并发用户数，是缓起步快结束，并不是瞬间结束

测试前的准备：使用jmeter中的插件安装jp@gc插件的安装并重启jmeter

负载测试的执行：添加线程组–jp@gc Stepping Thread Group

这个配置的测试场景是从20线程组进行增加，每次增加1个线程组，达到一个线程组就持续运行60秒时间，直到达到最大的线程数30，持续运行60s时间，最后在1s停止5个线程。看测试结果

添加监听器有三个,三个图要结合一起看：

jp@gc -Active Threads Over Time:查看并发用户线程的变化

jp@gc -Transactions per Second:查看tps的变化趋势图

jp@gc -Response Times Over Time:查看响应时间的变化

黄金分析法则：三者联动看 3 个阶段

阶段 1：加压 / 稳定期（线程上升，TPS 跟随上升）

• 现象：
  • 线程图：平稳上升或保持高位。
  • TPS 图：跟着线程数一起上升。
  • 响应时间图：平稳，没有明显上涨。
• 结论：系统处理能力充足，压力未达瓶颈，表现良好。

阶段 2：瓶颈临界点（线程继续涨，TPS 不涨，RT 暴涨）

• 现象：
  • 线程图：继续增加或维持高位。
  • TPS 图：达到峰值后不再上涨，甚至开始下降（出现平台期）。
  • 响应时间图：开始急剧上升（曲线陡增）。
• 结论：系统已达瓶颈！
  • 此时再加压，吞吐量上不去，只会让响应时间越来越慢。
  • 瓶颈可能在：CPU、内存、数据库连接池、IO、外部依赖等。

阶段 3：减压 / 下降期（线程下降，TPS 下降，RT 恢复）

• 现象：
  • 线程图：下降。
  • TPS 图：跟着下降。
  • 响应时间图：逐渐回落到正常水平。
• 结论：系统能自我恢复，没有发生死锁或雪崩，稳定性尚可。

4 种典型异常场景组合分析

场景 1：线程涨，TPS 不涨，RT 暴涨 → <