常见性能测试剖析
1、系统资源问题
CPU/内存/磁盘/网络...
2、语言/代码：
JVM/PHP-fpm ...etc
3、框架问题：
Sprint Boot /百度RPC...
服务单点性能问题
1、CPU负载
2、内存泄漏
3、磁盘IO
4、网络IO
5、JAVA Full GC
6、TCP连接数
7、工作线程打满
.....
案例1：某次压力测试，服务端CPU飙升打满，CPU计算型
TOP -H -p pid
Pstack pid
Trace -p pid
代码逻辑问题：
同步解析接口，使用正则方式匹配返回内容，但是由于返回内容过大，导致CPU飙升。正则，大数据的JSON序列化/反序列化
另外死锁问题也可以通过类似的方式调优
CPU不高，但服务响应耗时高，请求堆积；
案例2：某次压力测试，系统CPU等指标正常，但是偶发间断时间请求耗时特别高
JVM GC问题：
Full GC Stop the world
减少Full GC时间，老年代降低
案例3：某次压力测试，php程序，php-fpm内存增长，OOM导致服务挂掉
排查原因，使用了第三方so插件做JSON解析，但是第三方so插件有内存泄漏问题。
Max-request，fast-cgi 固定请求数后重启
案例4：某次压测，CPU/内存/网络 等指标表现良好，但响应耗时非常久
监控查看磁盘IO异常，追查发现日志级别设置为Debug，大量日志打印拖累性能
同步日志，可能是潜在的性能杀手
案例5：某次压力测试，CUP/内存/网络/磁盘 所有指标都表现良好，但是响应时间非常久
查看Nginx 日志，发现 request_time较长，但是 upstream_response_time 实际较短。
案例6：某次压测，同样的并发TPS，但是前期性能良好，后期数据库CPU飙升
压测会长生大量级的数据，数据增长会带来性能的损耗
压测数据不合理，导致统一设备关联多个用户，服务端不做限制的in查询
不合理分页，未做椰树limit，导致将数据库新增数据全部查询
案例7：某次稳定性测试，大并发TPS，前期性能良好，分片缓存，在模拟缓存单点失效大量的数据库穿透
缓存不合理的分片策略，使用分除模式。导致大量缓存统一时间失效。
不合理的负载均衡算法也会有类似的问题。
一致性的HASH解决此缓存问题
案例8：某次稳定性测试，如果HTTP入口流量仅百QPS，但下游RPC服务打卦
商户列表，for循环调用下游解决，导致请求数百倍扩大。
使用Batch接口减轻压力，Batch接口可能会带来功能隐患
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请联系我们举报，一经查实，本站将立刻删除。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/100683.html原文链接：https://javaforall.net
