性能测试 cpu_cpu性能测试分数

性能测试 cpu_cpu性能测试分数性能测试之如何分析CPU异常曲线性能测试为保证软件质量起到重要作用,对于交易量较大的应用系统,性能测试更是一个必不可少的环节。测试人员通常通过监测响应时间、吞吐量、应用服务器和数据库服务器的CPU及内存来衡量系统的性能是否达标,那么,在性能测试过程中,面对一些异常的指标数据,我们应该如何层层

性能测试之如何分析CPU异常曲线   性能测试为保证软件质量起到重要作用,对于交易量较大的应用系统,性能测试更是一个必不可少的环节。   测试人员通常通过监测响应时间、吞吐量、应用服务器和数据库服务器的CPU及内存来衡量系统的性能是否达标,那么,在性能测试过程中,面对一些异常的指标数据,我们应该如何层层剥茧,找到问题产生的原因?   如何聚焦、解决性能问题?笔者本次将总结移动端性能测试的经验,与大家分享如何应对CPU异常曲线。   一、性能测试发现的问题   本次是针对移动端应用进行性能测试,性能测试的交易分别为查询交易1、申请交易1、申请交易2、查询交易2和查询交易3。   在对5支交易进行混合疲劳8小时测试过程中,发现应用服务器的CPU使用率曲线呈现规律性的异常现象:混合场景疲劳发压几小时后,CPU使用率陡增,直至发压结束,曲线如图1所示。
性能测试 cpu_cpu性能测试分数
性能测试 cpu_cpu性能测试分数   图1 应用服务器CPU曲线   二、问题分析过程   
性能测试 cpu_cpu性能测试分数
性能测试 cpu_cpu性能测试分数   图2 问题分析流程图   1.发现问题时,初步猜测是由于环境不稳导致了CPU陡增,再次进行混合8小时疲劳测试,发现测试结果和最初的结果一致,排除环境因素。   2. 查询XMeter的运行日志,发现有Java.lang.OutOfMemoryError: Java heap space的报错信息,进而对Heapdump文件进行分析,并未发现导致该问题的代码块。随后修改堆内存配置,由原来的1.5G改为2.5G,再次混合疲劳压测8小时,压测结果如图3所示。
性能测试 cpu_cpu性能测试分数
性能测试 cpu_cpu性能测试分数   图3 应用服务器CPU曲线   压测结果显示:应用服务器的CPU使用率曲线开始陡增的时间较之前变长,堆内存为1.5G时,CPU使用率在发压开始2-3小时左右陡增,直至发压结束;堆内存为2.5G时,CPU使用率在发压开始5-6小时左右陡增,直至发压结束。   3. 项目组进一步验证环境的参数配置,将服务器由2C/4G扩容至2C/8G,增加数据库连接池数目和WAS线程数,再次进行混合疲劳压测,测试结果显示CPU仍然出现陡增现象,排除环境参数配置因素。   4. 测试人员对应用服务器CPU曲线、数据库服务器CPU曲线、TPS曲线和请求响应时间曲线进行综合分析,发现应用服务器CPU陡增的同时,数据库CPU和TPS曲线呈现下降趋势,平均响应时间曲线升高,因此初步将问题原因聚焦于应用服务器程序问题。   (1)请求响应时间
性能测试 cpu_cpu性能测试分数
性能测试 cpu_cpu性能测试分数   图4 请求响应时间曲线   (2)请求吞吐量
性能测试 cpu_cpu性能测试分数
性能测试 cpu_cpu性能测试分数   图5 请求吞吐量曲线   (3)数据库服务器CPU曲线
性能测试 cpu_cpu性能测试分数
性能测试 cpu_cpu性能测试分数   图6 数据库服务器CPU曲线   分析native_stderr.log,发现JVM堆内存使用量不断升高,堆内存回收异常,存在内存泄漏:
性能测试 cpu_cpu性能测试分数
性能测试 cpu_cpu性能测试分数   图7 JVM堆内存使用量曲线   5. 在确认是程序问题之后,通过对不同的交易进行压测来定位导致问题的交易:   (1)移动端交易单独压测由于陡增的时间节点是发压后3小时,分别对每支交易进行压测4小时,进而对不同的交易组合进行混合压测4小时,CPU陡增现象均未出现。   (2)PC端与移动端交易进行压测① 由于5支交易中仅申请交易2是旧交易,因此对PC端的申请交易2单独进行疲劳压测8小时,发现JVM堆内存使用率曲线显示正常;② 对PC端申请交易2,移动端:查询交易1、查询交易2、查询交易3这4支交易进行混合疲劳压测8小时,发现JVM堆内存使用率曲线显示正常;③ 对PC端申请交易2,移动端:查询交易1、查询交易2、查询交易3、申请交易1这5支交易混合疲劳压测8小时,问题复现,测试结果如图8所示。
性能测试 cpu_cpu性能测试分数
性能测试 cpu_cpu性能测试分数   图8 应用服务器CPU曲线   JVM堆内存使用量曲线如图9所示。
性能测试 cpu_cpu性能测试分数
性能测试 cpu_cpu性能测试分数   图9 JVM堆内存使用量曲线   初步确认申请交易1导致该问题出现,随后对申请交易1单独进行疲劳压测8小时,问题复现,确认该交易存在问题,测试结果如图10所示。
性能测试 cpu_cpu性能测试分数
性能测试 cpu_cpu性能测试分数   图10 应用服务器CPU曲线   JVM堆内存使用量曲线如图11所示。
性能测试 cpu_cpu性能测试分数
性能测试 cpu_cpu性能测试分数   图11 JVM堆内存使用量曲线   三、解决方案   项目组对申请交易1和申请交易2的代码进行单步调试,定位到出现内存问题的代码块,随后比对PC端和移动端交易代码,发现移动端交易代码未对申请单缓存数据进行清理,加入了清理缓存数据的方法后,再次对5支交易进行混合疲劳压测8小时,应用服务器的CPU曲线平稳,未出现陡增现象。   代码块采用了线程上下文方式对每笔申请单数据进行缓存,采用此种方法,需要用remove()方法对其进行清理,这样可以加速JVM的回收,否则,在高并发的情况下,会出现JVM堆内存使用量一直升高,堆内存回收异常的现象。   四、测试总结及反思   性能测试过程中,响应时间、吞吐量、CPU是衡量性能的关键指标,当响应时间、吞吐量符合通过准则时,并不意味着性能一定是正常的,还要CPU曲线是否正常。   1.及时查看相关的日志,如XMeter日志、Heapdump文件、java core文件和native_stderr.log文件,通过日志文件分析堆内存是否存在回收异常、内存泄漏或内存溢出等现象。   2. 问题复现的压测时间至少为8小时或8小时以上,本次性能测试中,问题复现的压测时间均为3-5小时,压测时间不足导致问题未能很好的复现。   3. 日志显示存在内存泄漏的现象后,要着重检查代码,而不应该持续的更改配置和参数。   4. 应及时对测试结果进行全面分析,包括应用服务器CPU曲线、数据库服务器CPU曲线、请求吞吐量和请求响应时间,这样更有助于快速定位问题来源。   5. 由于堆内存会在服务器重启之后进行清理,因此为了使每次测试都是从初始状态开始,测试之前应该重启服务器。   最后在我的sigusoft技术交流群里整理了我这10几年软件测试生涯整理的一些技术资料,包括:电子书,简历模块,各种工作模板,面试宝典,自学项目等。如果在学习或工作中遇到问题,群里也会有大神帮忙解答,群号 ( 备注 知乎555 )   全套软件测试自动化测试教学视频
性能测试 cpu_cpu性能测试分数
性能测试 cpu_cpu性能测试分数   300G教程资料下载【视频教程+PPT+项目源码】
性能测试 cpu_cpu性能测试分数
性能测试 cpu_cpu性能测试分数   全套软件测试自动化测试大厂面经
性能测试 cpu_cpu性能测试分数
性能测试 cpu_cpu性能测试分数

2024最新激活全家桶教程,稳定运行到2099年,请移步至置顶文章:https://sigusoft.com/99576.html

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。 文章由激活谷谷主-小谷整理,转载请注明出处:https://sigusoft.com/67823.html

(0)
上一篇 2024年 8月 8日 下午5:20
下一篇 2024年 8月 8日

相关推荐

关注微信