本文共 1057 字，大约阅读时间需要 3 分钟。

常见性能测试剖析

1、系统资源问题CPU/内存/磁盘/网络...2、语言/代码：JVM/PHP-fpm  ...etc3、框架问题：Sprint Boot /百度RPC...

服务单点性能问题

1、CPU负载2、内存泄漏3、磁盘IO4、网络IO5、JAVA Full GC6、TCP连接数7、工作线程打满.....

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

TOP -H -p pidPstack pidTrace -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://blog.csdn.net/weixin_42274846/article/details/127620580 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！