三、性能测试场景设计

• 一、引言：如果公司要求你去做性能测试，遇到这些场景，我们要如何设计？

  需求1： 活动页面，要你做性能测试， 看是否能满足1000个人同时访问

  需求2：对接的接口，如果要满足 50tps，这样的场景怎么设计

  需求3： 秒杀活动要看秒杀时，服务器能否支持500个人同时秒杀

• 二、6种常见设计方法

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

• 1、普通性能场景设计

  • 线程组

    • 1）线程数： 模拟的并发用户数量

      • 线程数，有没有限制呢？
        • jmeter本身是没有对线程数做限制
        • 但是， jmeter启动这些并发用户数时，需要消耗资源，受电脑cpu的主频限制，一台电脑不可能创建无限量的线程数
          • 实际的情况是比如http协议的脚本的线程数，大概能产生1500左右。2000个可能产生，但是可能会出错。1000左右比较保守，可能能产生。
          • 也就是说，1台电脑，http协议脚本，保守估计是可以产生1000个并发用户数
          • 如果你想模拟超过1000并发用户数，你可能需要考虑 分布式来实现

    • 2）ramp-up时间

      • 启动所有线程的时间(前提：线程数设置在合理的范围)
      • 在ramp-up时间结束点，所有的线程都会启动
      • 案例：5s内启动300个线程
      • 在ramp-up时间内，是否均匀产出并发用户数，是无法确定的（拿上面的例子举例，不能保证每秒启动60个线程）
      • 在启动时间内，产生的并发用户数，一产生，就会去发起请求
      • 启动了并发用户，就会去发起请求，不同时间产生的并发用户数，与前面产生的并发用户数，调用的接口可能不一样
      • jmeter做性能测试，更多时候，使用的是，广义并发
      • ramp-up时间要大于等于1
      • 线程数和ramp-up时间，怎么设置才比较合理？
        • 500以内并发用户， ramp-up时间建议设置2~4s
        • 500-1000的并发，ramp-up时间建议设置5s
        • >1000 ramp-up时间建议设置5-8s
        • 一个原则：
          • ramp-up时间在总执行时间中，占比要很低（比如你总执行时间是10s，那上面那些建议时间就太高啦hhh）。
          • 一般的情况，一个性能测试的总执行时间是几十秒钟~几十分钟

    • 3） 循环次数
      

      • 默认必须大于等于1
      • 循环次数，就是每个并发用户数要去执行的请求数量
      • 如果勾选了永远选项，就会一直循环，直到你点击停止
        • 这个停止会有问题吗？
          • 如果勾选了永远后点击停止，会导致请求报错或卡死
          • 这个选项要与调度器 一起使用
        • 调度器：
          • 持续时长：设置持续时长（s）
          • 启动延迟：设置延迟时长（s），一般真正做性能测试的时候不用
        • 实践：300个并发用户，持续运行300s（忘了截图了，先把数据贴上来吧，尴尬。我们的脚本可以加上聚合报告和响应时间图）
          • 聚合报告如下： avgRT： 0.117s 90%RT：0.262s avgTPS： 2544.9
          • 结论：
            • 90%RT：0.262s 可以看到，这个响应时间是比较快的，因为用户满意度指数1.5s
            • 300个人， avgTPS： 2544.9 tps>user 那么，每个人1秒钟发了约8个请求，所以，我们本次300个并发用户数，未超过这个接口能承受最大并发用户数
            • 可以简单得到一个结论： 这个查询接口最大并发用户数大于300

• 2、负载测试性能场景

  • 负载测试： 逐步增加并发用户数
  • 我们可以下载插件实现这个功能 下载插件步骤
    • 插件管理： jpgc（这里后面记得加个空格，否则搜不到哦） 安装这个插件
    • 添加方式：线程组-jp@gc stepping thread group
    • 这种线程组，只能设计出，stepping 是相同的情况，如果想要设计步长相同/不相同的阶梯线程组，可以使用Ultimate Thread Group
      
    • 总共启动100个线程，然后用5秒钟增加10个并发用户数，持续运行30秒。当100个线程全部启动后，持续运行60然后每1s逐步停止5个线程

  • 完全不知道项目的性能瓶颈范围时，我们怎么设置？

    • 答：我们可以从0 - 100,200…逐步加压，这样就可以找到瓶颈啦~

  • 已经找到一个范围了，怎么设置？

    • 答：举个栗子，比如我们已经找到了最大的范围是20-30，那我们可以设置总线程数为30，然后设置每60s增加1个线程，然后设置那个线程的启动时间为1s，持续60s。最后每1s停止5个线程，直到最终停止
      

  • 那么线程组跑完以后，我们要怎么查看呢？

    • 我们可以通过添加监听器的方式进行查看，gc为我们提供了5个监听器
      • jp@gc - Active Threads Over Time：随着时间变化的并发用户数图
      • jp@gc - Flexible File Writer
      • jp@gc - PerfMon Metrics Collector
      • jp@gc - Response Times Over Time：响应时间和随着时间变化的响应时间图
      • jp@gc - Transactions per Second ：tps的图，可以看成功和失败，如果这边显示失败，可能表示服务器已经到达瓶颈
        

    ps：分析的时候可以多张图一起看

  • 我们思考个问题，增加的这个量，一定相同吗？
    • 答： 增加的量(步长)，可以相同，也可以不相同
      • 相同只是一种特殊请求 stepping threads group（就是上面这个）
      • 不相同的增量，是不能用这个的

• 在阶梯线程组，执行过程中，我们的并发用户数是时刻发生变化
• 阶梯线程组设计的规律：
  • 缓起步，快结束
    • 快结束： 并不是瞬间结束，只是相对缓慢的结束，为什么要这么做呢，因为如果立刻停止，可能导致服务中断而报错（把这种人为导致的错误算在服务器头上显然是不合理的）
• 阶梯线程组可以看聚合报告吗？
  • 答：聚合报告中的数据，都是平均值。在负载场景/阶梯场景，看了也没有意义
• 但是这边注意一点，性能测试时，能不启用监听器，则不启用
  • 真正做性能测试，怎么做呢？
    • CLI-mode 无图形界面模式 命令行
    • GUI-mode 仅仅用于编写调试脚本
  • 没有监听器，我们怎么知道性能测试结果？
    • jmeter的html报告，与是否启用添加监听器无关，不信我们可以测试下。我们在不添加监听器的情况下，先在工具里点击generate html report，然后把jtl文件导入第一个，选择jmeter.properties/user.properties导入第二个，然后新建一个空文件夹，导入第三个，然后点击生成，然后查看报告，一样可以看到结果
      
      
      

• 3、压力测试场景

  • 特点：长时间，看稳定性
  • 具体我们要怎么设计压力测试场景呢？
    • 比如我们有个接口的最大的并发数是29，那我们可以这么设计：

    • 29 * 20% = 6 我们可以用20%的线程，就是6个线程压10h
      

    • 29 * 80% = 24 我们可以用80%的线程，就是24个线程压10h，这个我们用阶梯测试的方式来演示
      

• 4、面向目标性能场景

  • 1、Arrival thread group （达到多少tps）

  • 需求： 期望我项目的接口，能满足50tps

    分析：
    • 50tps表示每秒50个事务
    • 我们为什么得出要50t/s呢，我们可以来算下：
      • 1分钟： 50*60s = 3000个事务
      • 1小时 3000 * 60 = 180000 事务，就是1小时要处理18w个请求
      • 10小时就是180w，24h就是432w个请求
      • 单纯一个接口都能支持这么大的请求了，而且还有其他接口帮忙分担流量。中小微企业的产品日均访问量约为千万， 50tps基本已经能满足要求了
    • 那我们要怎么设计这个场景呢？

      • 是直接用50个人去发请求吗？但是这样是不准确的，如果50个人做并发没达到50tps，就表示产品不能达到50tps吗？这种想法不准确，也许是人不够，jmeter有这个插件可以实现这个功能，我们可以在添加线程时候选择arrivals thread group，然后进行设置
        

      • target rate：目标比例，我们的需求是达到50tps，所以这里设置为50

      • ramp up time：多少秒内启动所有线程

      • ramp up steps：在上面设置的时间内，最多有多少次启动的机会，一般会多设置几次（和上面的参数配合使用）比如我设置5次，但是第3次就满足需求了，就不会继续启动了

      • hold target rate time： 达到这个目标后持续运行多长时间

      • 我们开始测试：这里可以看出需要150个人才能达到50tps
        
        也确实达到了50tps
        
        表面上是ok了，但是看响应时间这边，最大达到10s，平均响应时间约为4s，是不能接受的，所以这次测试还是失败啦~
        

• 2、Concurrency Thread Group（达到多少人/并发）

• 作用：

  • 1、提供了用于配置多个线程计划的简化方法

  • 2、并大线程不够，运行线程中启动额外的线程 ----保持并发水平

  • 3、可以更好的模拟用户行为，控制测试的时间

  • 需求： 期望支持1000个人秒杀，系统不能崩溃

    • 我们该怎么实现呢，可能一开始想这么简单粗暴的来。。这种只是秒杀里最简单的一种情况了，秒杀的实质是1000个人访问我们系统，系统要持续运行一段时间且不能崩溃。而且1s要并发1000个，服务器压力过大就会出现异常，并不是服务器处理能力不行
      

    • 站在用户角度，用户理解的是要在1s内收到处理结果，期望结果可以理解成1000tps

    • 怎么实现呢？首先我们添加线程组，选择Concurrency Thread Group，配置的参数其实和上一个有点像，就是第一个不一样
      

    • 我们实际操作下，这里第一个参数替换成100，因为要被压测的接口太弱了hhh
      我们可以看到这个是合格的，达到100了
      

    • tps也没有报错
      

    • 但是平均响应时间达到5s，太夸张了
      

    • 结论：这个接口不能支持100个并发用户数

3、Ultimate Thread Group 终极线程组（模拟有时间规律的场景）

• 特点：有时间规律，波浪型

• 适用场景：比如说是外卖点餐，高峰期是在午餐晚餐期间，其他时间段相对比较平稳

• 注意：后面那行initial delay的值要大于等于上一行值的总和，否则就设计不出波浪线型了

• demo：

  • 比如我要添加第二行，第三行阶梯，期望结束时间是重合的，要怎么做呢？

    • 首先第一行结束时间要大于后面时间之和
      

    • 现在我要添加第二行，期望在第一个运行30s后开始启动，就要在第一行阶梯的（initial delay+starup time）+30s，就是60s，持续时间就是240-60=180s
      

    • 现在我要添加第三行，也同样期望在原有时间+30s，那initial delay就是上一行的initial delay+startup time+30=120s，然后持续时间就是240-120s=120s
      

    • 依此类推
      

• 规律

  • 下一行的初始化时间=上一行的initial+startup time+你期望多长时间后启动第二个波浪的时间

  • 每一行的initial+hold load for要相等，这样才能保证在相同的时间点结束

  • 参数

    • start threads count：启动线程数
    • initial delay，sec：初始延迟启动时间/秒级
    • startup time，sec：起始时间/秒级
    • hold load for，sec：持续时间/秒级
    • shutdown time：在几秒内关闭

• 问题： 我的脚本，期望在启动之后，运行一段时间，暂停，然后过一段时间之后，再运行？

  • 1、jenkins中的定时任务 √ 但是，这种方式，需要大家掌握Jenkins中定时任务的配置

  • 2、Ultimate Thread Group 下一波浪的起始时间大于 前一个波浪的所有时间之和

• 5、混合场景设计

  • 不同数量的并发用户数，向不同接口发起请求—这种才是真正的混合场景，才真正符合企业产品实际情况
  • “假”混合场景：在一个线程组中，添加逻辑控制器，控制我们脚本的运行，这种，是把脚本混合了， 但是与生产的情况还是有差异。
  • demo（详细的不写了，涉及接口关联的可以看看前面文章怎么处理，比如添加个调试取样器，然后用函数助手的setProperty和getProperty函数设置和取出）

    • 为了避免参数重复，还可以加个threadNum函数啥的
      

    • 总体大概是这样

      • 跨线程组传参
        • 线程组1 40
        • 线程组2 20
        • 线程组3 10
          

注意：在做性能测试时，不要连续去执行性能测试，在前一轮性能测试结束的时候，要休息一会，等待服务器的压力释放，再开始下一轮性能测试，不然，因为前面的性能测试导致服务器压力过大，未释放，从而影响后续性能测试结果。