软件测试中常见的七个性能问题案例分析

　　在用户场景不确定的情况下，我们为了保障软件的正常运行就必须对软件的性能进行测试。下面我们一起来看看在软件测试中常见的性能问题，希望大家可以通过这七个比较典型的案例分析，充分掌握各种性能问题的解决方法。

　　案例一：某次压力测试，系统CPU等指标较正常，但偶发间断时间请求耗时特别高

　　|[Full GC (Ergonomics) [PSYoungGen: 944K-> 890K(2048K)]

　　[ParOldGen: 7129K-> 7129K(7168K)18074K->8019K(9216K),

　　[Metaspace: 3357K-> 3357K(1056768K0], 0.1213761 secs| [Times:

　　user=2 sys=0.00, real=2 secs]

　　JVMGC问题:

　　Full GC Stop the world

　　减少FullGC时间，老年代降低

　　案例二：某次压力测试，php 程序, php-fpm内存增长，OOM导致服务挂掉。

　　排查原因，使用了某第三方so插件做JSON解析，但第三方so插件有内存泄漏问题。

　　Max-request, fast-cgi 固定请求数后重启。

　　案例三：某次压力测试，同样并发TPS,但前期性能良好，后期数据库CPU飙升

　　压测会产生大量级的数据，数据增长会带来性能的损耗

　　压测数据不合理，导致统一设备 关联多个用户，服务端不做限制的in查询

　　不合理分页，未做页数limit,导致将数据库新增数据全部查询

　　案例四：某次稳定性测试，如果HTTP入口流量仅百QPS，但下游RPC服务打挂。

　　商户列表，For 循环调用下游解决，导致请求数百倍扩大。

　　使用Batch接口减轻压力，Batch 接口可能带来的功能隐患。

　　案例五：某次稳定性测试，大并发TPS，前期性能良好，分片缓存，在模拟缓存单点失效后大量数据库穿透。

　　缓存不合理的分片策略，使用除模方式。导致大量缓存统-一时间失效。

　　不合理的负载均衡算法也会有类似问题。

　　一致性Hash解决缓存问题。

　　案例六：某次压力测试，服务端CPU飙升打满。CPU计算型

　　Top -H -P pid

　　Pstack pid

　　Trace -p pid

　　代码逻辑问题：

　　同步解析接口，使用正则方式匹配返回内容，但由于返回内容过大，导致CPU飙升。正则，大数据的JSON序列化反序列化。

　　另外死锁问题也可以通过类似方式调优CPU不高，但服务响应耗时高，请求堆积。

　　案例七：某次压力测试，CPU/内存/网络 等指标表现良好，但响应耗时非常久。

　　监控查看磁盘I0异常，追查发现日志级别设置为Debug，大量日志打印拖累性能。

　　同步日志，可能是潜在的性能杀手。

　　以上内容为大家介绍了软件测试中常见的七个性能问题案例分析，本文由多测师亲自撰写，希望对大家有所帮助。了解更多软件测试相关知识：https://www.duoceshi.com/xwzx-hydt/