性能实战之测试执行阶段
2022-09-19 20:57 第二个卿老师 阅读(170) 评论(0) 编辑 收藏 举报性能测试准备阶段结束后,就来到了测试执行阶段。
测试执行阶段
这个阶段算是性能测试最有魅力的,围绕着场景执行与调优,是大展身手的地方。
场景为什么要跟调优放在一起,因为从实际执行中来看,它们是密不可分的。
场景执行
场景就类似功能测试的用例,有着对应的目的,功能测试的用例是为了发现缺陷,而性能场景就是为了发现性能瓶颈。
第一篇需求分析中说到性能场景分为了4类:基准场景、容量场景、稳定性场景、异常场景。而每一个场景的目的不一样,可以依次按照顺序执行。
基准场景
基准场景是需要首先执行的,和我们常见的性能测试很相似,本质就是单接口的压测,目的是找到单接口或单业务的最大TPS。
第一步:设置场景的执行参数,以jmeter为例,主要包括线程数,Ramp-Up时间,场景执行时间等,如下图
注:我一般以5分钟递增,5分钟持续做为正式场景跑,可以根据时间情况调整。
那么如何确定线程数?先跑一次单线程的结果,根据平均响应时间计算所需的线程数 = TPS*RT/1s=800*0.172s/1s =137.6,我们可以往上取150试试。
第二步:执行场景,观察收集结果,我这边搭建了jmeter结果收集平台,可以实时看,如下图
注:观察jmeter的TPS与响应时间曲线,以及服务器的全局监控情况,然后分析并准备接下来的动作,如果有事务报错的情况,优先解决。
第三步:根据场景执行情况,调整执行策略,常见如下
- 情况一:TPS上不去,资源够用
- 情况二:TPS上不去,资源不够用
- 情况三:TPS能上去,资源不够用
这里贴一个首页单接口场景,前面需求分析阶段提到至少要满足800TPS,目前TPS 2.6K,RT 33ms已经达到了。
再看看应用服务器的资源利用率,CPU 70%,内存 50%,网络带宽约100Mb/s。
TPS目标达到,资料利用率不算低,那就暂时不动它。
再贴一个单接口场景,能看出TPS 约70,RT 约600ms,TPS未达到,资源也没有利用上。
应用服务器的资源利用率,CPU 4%,内存 50%,网络带宽约2Mb/s:
这时TPS与资源都没有达到目标要求,这种就需要先解决,进入场景调优。
因为调优是无止境的,所以在控制成本下,先解决优先级高的接口。
场景调优
首先场景调优就是对场景进行性能分析,再找出瓶颈并解决的一个过程。一般情况下场景执行跟调优都是交叉进行的。
如何进行性能分析呢?可参考高楼老师的“RESAR性能分析七步法”:
![](https://img2022.cnblogs.com/blog/992633/202208/992633-20220813102844074-692333194.png)
这七步分析逻辑就是从表现开始,找出证据,再一步一步的深入定位,找出问题实质的过程。
压力场景数据分析
针对上面的登录场景,首先我们看TPS,和响应时间曲线:
发现在时间在14:14与14:15中间后,随着压力的增加,响应时间也随着增加,而TPS也不再增加,这时就已经出现了性能瓶颈。
分析架构图
架构图是用来分析流量的路径,这里非常简单:
压测服务器——〉服务器A(nginx,zuul服务)——〉服务器C(用户服务)——〉网关服务器B(mysql,redis)
拆分响应时间
可以使用日志打印的方法,也可以安装APM链路监控工具,主要是确定时间消耗在那个链路上。
全局监控分析
这里我跳过了上一个步骤,因为全局监控中我看到了数据库的服务器压力较大,如下
进入数据库所在的网关服务器A,使用top命令查看,发现是mysql占用比较大,因为user表有10万条数据,猜测瓶颈在这。
定向监控分析
于是对mysql进行定向分析,其实Prometheus也可以监控mysql,可以直接分析场景执行时的mysq资源计数器。
我这里直接问开发要的sql,因为登录就是查询用户,如果新用户会进行插入sql。而我的场景用户数据都是老用户,所以只是查询,猜测这里出现了问题。
判断性能瓶颈
为了验证猜测是否正确,直接查看sql的执行计划(expalin),通过type列可知(忘截图了),没有用到索引,数据量小还好,数据量一大就非常明显。
确定解决方案
所以直接加上索引,如下
再次跑一下场景,结果如下:
13:42之前由于是老用户所以不用插入,TPS高,后面全是新用户,需要插入数据,即新用户的TPS达到了1.6k,比之前提升了十几倍,索引不愧为性能提升利器。
这里大家可能会发现,不同的测试数据对TPS影响很大,于是我还做了全部新用户、新老用户比1:1的场景。
执行情况归档
上面只是一个单接口的场景,实际上一整遍流程下来,我还遇到了其他瓶颈,后面有机会单独说说。
我会把整个执行与调优的过程都记录下来,方便后续追溯。
其实基准场景除了执行各单接口的场景外,还要进行业务级场景,比如多个接口一起组成的业务操作场景(比如登录,包括获取验证码和登录两个接口),而每个场景都可以按照这个流程来实施,最后使场景到达TPS目标。
容量场景这里我没写,后续补充,至于异常和稳定性场景,这次由于时间原因,也没有考虑,下期就是报告结论阶段了。