工商个人营业执照注册官网,深圳网站优化服务,互联网建站公司有哪些,慧聪网seo页面优化性能测试场景的重要程度类似于业务测试的 case#xff0c;case 是你进行业务测试的指引#xff0c;case 是否完善也直接决定了测试的覆盖率。同理#xff0c;场景是传递执行性能测试的步骤和目的#xff0c;关于这两点是你一定要清楚的。
首先认识下最重要的三个性能场景case 是你进行业务测试的指引case 是否完善也直接决定了测试的覆盖率。同理场景是传递执行性能测试的步骤和目的关于这两点是你一定要清楚的。
首先认识下最重要的三个性能场景基准场景、单接口负载场景、混合场景负载测试这几个场景也是经常说的“基石场景”。接下来讲解这三个场景是怎么操作以及核心目的是什么
基准场景
基准场景是指单线程或者少量线程一般在 5 个线程以下对单接口进行测试然后将测试结果作为基准数据在系统调优或者评估的过程中通过运行相同的业务接口比较测试结果为系统的优化以及后续测试流程提供决策数据。
有人觉得基准测试并不是在高并发下进行的不算是性能测试但我认为这其实是性能测试中重要的基础步骤它有以下作用
验证测试脚本及测试参数的正确性同时也可以验证脚本数据是否能够支持重复性测试等通过少量线程访问系统获取结果数据作为对比参考基准根据测试结果初步判断可能成为系统瓶颈的场景并决定是否进行后续的测试基准场景的结果被一部分公司作为上线的基线指标不达到要求是不允许上线的这样的场景也经常被固化成自动化的脚本定时触发和巡检。
单接口负载场景
单接口负载场景就是通过模拟多线程对单接口进行负载测试。我的具体做法是选定线程数后持续循环运行一定时间比如分别运行 100 线程、200 线程、300线程等一般相同线程数运行 1015 min然后获取事务响应时间、TPS、报错率监测测试系统的各服务器资源使用情况CPU、内存、磁盘、网络等把具体数据记录之后再开始跑下一个线程数。每一组线程数级别会有对应的 TPS直到你找到 TPS 的拐点。如下图所示横坐标是线程数纵坐标是 TPS线程数增加到 400 时出现了拐点。 需要注意的点有两个。
使用工具做性能测试时动辄就是上千的线程数所以如果你是一位初学者我更加倾向于你从一个相对比较低的线程数梯度增加这样才能够比较清晰地找到 TPS 的拐点。我还建议为每个虚拟用户级别做单独的场景网上绝大部分的教程在一个场景中做了很多梯度如下图所示这样只是看上去简单方便一些其实很不利于分析和诊断这个方式我并不推荐。因为并不是每一个量级的性能表现都是类似的而且一个场景多梯度出来的报表也可能没你想象中的清晰明了。在 JMeter 的聚合报告中还会将结果数据平均化这样的方式并不能准确地记录每个线程梯度对应的 TPS。而在一个场景里先固定虚拟用户可以将自己的精力聚焦在诊断上。 混合场景负载测试
混合场景是性能测试中最重要的场景之一这个场景是为了最大程度模拟用户真实的操作。真实的线上操作不只有单接口的操作一定是多种业务同时在进行比如张三在浏览商品李四在添加购物车等。
所以混合场景测试会将多个接口按照实际大促时候的比例混合起来然后增加线程数找出多个接口 TPS 的和对应的峰值。这个比例也是混合场景的关键在[《07 | 你真的知道如何制定性能测试的目标吗》]中已经较为详细地阐述了制定比例的方法本讲就不再赘述。加用户运行的基本策略可以参考上文的单接口负载测试。混合场景执行除了要观察总的 TPS还有一个非常关键的因素就是如何控制接口之间的调用比例使其不能偏离预期。
如何使用 JMeter 去控制场景比例
相信你已经知道线程数可以改变接口的 TPS但是如果每次通过线程数调整这个过程会比较烦琐。JMeter 提供了一个能较好地解决这个问题的插件叫作吞吐量控制器它在逻辑控制器组件中如下图所示 我来简单介绍一下这个插件配置规则默认的情况下使用的是百分比模式也就是 Percent Excutions。吞吐量一栏对应的是 TPS 占比我用 login 和 register 这两个接口来模拟下
login 接口配置比例是 80%如下图所示剩下的 20% 配置给 register。 看下运行后的效果可直接在 JMeter 中添加聚合报告元件如下图所示 实际计算下来的值为 1778.2⁄2222.7≈0.8这个数据是比较准确的。
以上是我所说的基石场景包括基准测试、负载测试、混合场景测试等这三个场景是有依次执行的顺序关系的按照顺序执行更容易发现问题且减少不必要的工作比如你连基准测试都不通过就没有必要进行负载测试了。所以我们在做每一次性能测试时都不应该省去或者颠倒上述的场景步骤。
接着我带你继续学习其他性能测试场景为了达到相对应的性能测试目的这些场景可以根据需求进行选择。
异常性能测试
性能测试也是存在异常测试的顾名思义就是在系统异常的情况下看系统的处理能力或者是通过处理后的恢复能力是如何的。
比如在架构的高可用方面遇到服务的上下线、数据库的主从切换等这些情况的时延是多少、处理能力能不能达到预期标准。另外在目前的电商应用架构中大促遇到紧急情况经常需要限流和熔断可能你经常听到这两个词但不是特别清楚两者的区别。
限流就是控制单位时间内的请求量比如说早晚高峰坐地铁很多入口都会放隔离带降低乘客流动速度这就是一种限流方式。
熔断就比较直接了当判断到调用的依赖服务报错到达一定数量后直接返回一个既定的数据将不再访问该服务。就像家中的保险丝一样到达一定条件后会自行断电以保障电路安全。所以我们也会测试触发限流和熔断所设置的阈值并观察在触发后的系统表现是如何的。
稳定性性能测试
性能测试中的稳定性测试是通过给系统加载一定压力的情况下运行较长一段时间验证系统是否稳定。通常是采用典型混合场景应用系统运行 72 小时查看系统运行指数是否平稳。
稳定性测试的注意点
稳定性测试在性能测试中是一个相对严苛的场景因为在 72 小时中可能发生的事情太多了不仅仅是业务承载的问题还包括你准备的数据、客户端稳定性甚至硬件设备断网断电等。任何一项意外的发生都会造成场景的失败。稳定性测试的监控级别也应当更高一旦有问题立即钉钉或者电话通知所以稳定性测试之前需要有充足的预案和监控报警。
经常被问到的问题
什么情况下可以停止负载测试
有同学问我无论是单接口负载测试还是混合场景的负载测试都是梯度增加线程数那线程数增加到多少程度才可以停止呢
首先我们结合图 1 可以看到在梯度增加线程数时TPS 一般会随之发生变化当你能够根据 TPS 的变化找到相应的峰值且这个值也是符合预期时便可以停止负载测试了。
但是现实的情况并没有这么理想很多时候当你还没有发现图 1 中的拐点时接口就可能在报错了那遇到这样的情况是继续测试还是停止测试呢这其实是一个约定的问题即测试的结束条件是什么
理想的情况下自然是达到目标就停止了。那不理想呢根据我的经验会在测试之前组内协商出场景异常情况下的停止条件比如 CPU 达到 70%响应时间超过 500 ms接口正确率低于 99% 等当触发这些条件时我将不会继续加线程进行测试了。
混合场景我选取哪个线程梯度的访问量进行测试
这个问题经常被问到一些同学喜欢基于峰值处理能力去进行稳定性测试这是一个很严格的要求。其实标准因公司的实际体量而异。今年的某电商双 11 实时支付峰值达到 50 w/s有可能这个值也未必能平稳跑 72 h但以这个访问量为执行标准已经足够用了。所以对于不同的公司而言自行选择适当的线程梯度就可以。我经常听到一句话今年的峰值流量就是明年的正常流量对于这样飞速发展的公司我想还是需要基于峰值去执行稳定性测试场景。
关于场景的命名一直有同学很困惑感觉对于同样一个场景怎么有的人说是混合场景还有同学说是容量场景。关于场景名字的叫法不仅不同的公司会不一样就包括参考资料上也没有形成非常统一的规范但我认为并不需要用很多精力研究场景的叫法但你一定要能描述清楚场景的核心目的是什么执行步骤是什么这才是需要向你的协作伙伴传递的最准确的信息。
总结
本文系统地学习了性能测试的场景设计关于三大基石场景的作用以及意义混合场景的操作方法以及稳定性场景的注意事项。
