三、性能测试场景设计

性能测试场景设计

    • 一、引言:如果公司要求你去做性能测试,遇到这些场景,我们要如何设计?
    • 二、6种常见设计方法
      • 1、普通性能场景设计
      • 2、负载测试性能场景
      • 3、压力测试场景
      • 4、面向目标性能场景
        • 1、Arrival thread group (达到多少tps)
          • 需求: 期望我项目的接口,能满足50tps
        • 2、Concurrency Thread Group(达到多少人/并发)
          • 需求: 期望支持1000个人秒杀,系统不能崩溃
        • 3、Ultimate Thread Group 终极线程组(模拟有时间规律的场景)
      • 5、混合场景设计

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

    需求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个线程三、性能测试场景设计_第1张图片
        • 在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) 循环次数
        三、性能测试场景设计_第2张图片

        • 默认必须大于等于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
        三、性能测试场景设计_第3张图片
      • 总共启动100个线程,然后用5秒钟增加10个并发用户数,持续运行30秒。当100个线程全部启动后,持续运行60然后每1s逐步停止5个线程
    • 完全不知道项目的性能瓶颈范围时,我们怎么设置?

      • 答:我们可以从0 - 100,200…逐步加压,这样就可以找到瓶颈啦~
    • 已经找到一个范围了,怎么设置?

      • 答:举个栗子,比如我们已经找到了最大的范围是20-30,那我们可以设置总线程数为30,然后设置每60s增加1个线程,然后设置那个线程的启动时间为1s,持续60s。最后每1s停止5个线程,直到最终停止
        三、性能测试场景设计_第4张图片
    • 那么线程组跑完以后,我们要怎么查看呢?

      • 我们可以通过添加监听器的方式进行查看,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的图,可以看成功和失败,如果这边显示失败,可能表示服务器已经到达瓶颈
          三、性能测试场景设计_第5张图片

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

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

    • 特点:长时间,看稳定性
    • 具体我们要怎么设计压力测试场景呢?
      • 比如我们有个接口的最大的并发数是29,那我们可以这么设计:
      • 29 * 20% = 6 我们可以用20%的线程,就是6个线程压10h
        三、性能测试场景设计_第9张图片

      • 29 * 80% = 24 我们可以用80%的线程,就是24个线程压10h,这个我们用阶梯测试的方式来演示
        三、性能测试场景设计_第10张图片

  • 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,然后进行设置
          三、性能测试场景设计_第11张图片

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

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

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

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

        • 我们开始测试:这里可以看出需要150个人才能达到50tps
          三、性能测试场景设计_第12张图片
          也确实达到了50tps
          三、性能测试场景设计_第13张图片
          表面上是ok了,但是看响应时间这边,最大达到10s,平均响应时间约为4s,是不能接受的,所以这次测试还是失败啦~
          三、性能测试场景设计_第14张图片

  • 2、Concurrency Thread Group(达到多少人/并发)

  • 作用:

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

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

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

    • 需求: 期望支持1000个人秒杀,系统不能崩溃
      • 我们该怎么实现呢,可能一开始想这么简单粗暴的来。。这种只是秒杀里最简单的一种情况了,秒杀的实质是1000个人访问我们系统,系统要持续运行一段时间且不能崩溃。而且1s要并发1000个,服务器压力过大就会出现异常,并不是服务器处理能力不行
        三、性能测试场景设计_第15张图片

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

      • 怎么实现呢?首先我们添加线程组,选择Concurrency Thread Group,配置的参数其实和上一个有点像,就是第一个不一样
        三、性能测试场景设计_第16张图片

      • 我们实际操作下,这里第一个参数替换成100,因为要被压测的接口太弱了hhh
        我们可以看到这个是合格的,达到100了
        三、性能测试场景设计_第17张图片

      • tps也没有报错
        三、性能测试场景设计_第18张图片

      • 但是平均响应时间达到5s,太夸张了
        三、性能测试场景设计_第19张图片

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

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

  • 特点:有时间规律,波浪型

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

  • 注意:后面那行initial delay的值要大于等于上一行值的总和,否则就设计不出波浪线型了三、性能测试场景设计_第20张图片

  • demo:

    • 比如我要添加第二行,第三行阶梯,期望结束时间是重合的,要怎么做呢?
      • 首先第一行结束时间要大于后面时间之和
        三、性能测试场景设计_第21张图片

      • 现在我要添加第二行,期望在第一个运行30s后开始启动,就要在第一行阶梯的(initial delay+starup time)+30s,就是60s,持续时间就是240-60=180s
        三、性能测试场景设计_第22张图片

      • 现在我要添加第三行,也同样期望在原有时间+30s,那initial delay就是上一行的initial delay+startup time+30=120s,然后持续时间就是240-120s=120s
        三、性能测试场景设计_第23张图片

      • 依此类推
        三、性能测试场景设计_第24张图片

  • 规律

    • 下一行的初始化时间=上一行的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函数啥的
        三、性能测试场景设计_第25张图片

      • 总体大概是这样

        • 跨线程组传参
          • 线程组1 40
          • 线程组2 20
          • 线程组3 10
            三、性能测试场景设计_第26张图片

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

你可能感兴趣的:(jmeter,性能测试)