JMeter性能测试工作中遇到的问题及剖析，你遇到了几个？

常见性能测试剖析

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接口可能会带来功能隐患```