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

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

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

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

二、6种常见设计方法

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
    
  • 总共启动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：分析的时候可以多张图一起看