1、怀疑过资源不够问题，但通过资源监控 CPU、disk 均没超过 40%
2、怀疑是数据库连接池问题，但增大相关连接池没有取得很大的进展
3、怀疑是代码方面问题，但接口也挺正常，开发人员表示没性能限制
4、有采用 nginx 域名映射，即并发的接口是域名，然后域名解析到 A 服务器的 NGINX，A 服务器再发送请求到 B 应用服务器
大家可以给点分析意见吗，目前都没有一个较好的排查思路和想法。谢谢啦！
16 天，一个回复都没有...
从这 3 个图看：
1、出现这个情况的时候，线程数已经没有变化了，说明压测工具在全负荷运行，且每个线程都是收到返回后再会产生新的请求，即新的样本
2、从 tps 看，有出现 failture（原因图里没看到，不清楚），同时 response time 也挺大的（有不少在 3s 以上）。
3、没看到具体脚本内容，不确定有没有集合点之类的东西。
根据上面的信息分析：
1、样本数没增大说明存在等待，而结合上面说的第一点，等待的原因有可能是在等待服务端的返回，也有可能是脚本本身有等待类逻辑（常见的有集合点）
2、如果是服务端在等待，且楼主说了物理资源消耗不大（CPU、disk 不大，内存和网络未知但一般不至于出问题），可以排除是服务器本身物理资源不足，但有可能是分配给程序的资源不足。这个可以看程序相关的监控（如 java 应用的话，看 jvm 参数）
3、楼主图一有提到当样本增加停止时，被测服务的 cpu、tomcat 也下降，如果确实如此的话，说明样本增加停止时压力是降低了，有可能不是服务端处理慢（这种情况下资源消耗不应该下降），而是压测工具自己在等待。这个需要具体分析脚本里有没有什么 wait 相关逻辑（比如集合点之类的）
如果上面的分析思路都发现走不通，建议补充一些数据：
1、tps 图里面失败的具体原因贴一下
2、压测过程里，同一时间被测系统的相关监控指标曲线也给一下
3、整个脚本参数脱敏后发一下，看有没有什么和等待有关的配置
陈恒捷
回复
1、你说的第一点，“线程数已经没有变化了”（这里我不太明白，因为 jmeter 是在开始的时候就要设置指定的线程数吗，这里设置了 30 个并发线程那肯定只能看到 30 的线程数）
2、至于样本数的 failture，就是报的 connection time out
3、脚本没有设置特殊的集合点，就基本配置
4、还有应用的 jvm 参数已经改过，相应增大到 2048m 没什么不一样，还是会出现这样 “暂停” 情况。所以当时就排除是应用 JVM 的问题。
5、后面做了测试，如果不使用域名进行压测的话，是不会出现样本数 “暂停” 的情况。直接对 IP 进行压测，不走 nginx 域名，直接压 ip，没什么问题。所以定位到 nginx 相关的一些配置问题，但修改 nginx 的性能配置还是没生效。目前还在调试排查中...
啊神
回复
1、你说的第一点，“线程数已经没有变化了”（这里我不太明白，因为 jmeter 是在开始的时候就要设置指定的线程数吗，这里设置了 30 个并发线程那肯定只能看到 30 的线程数）
jmeter 一样可以通过插件设定线程数上升策略的。一般压测策略，线程数应该是逐步上升，而不是一上来就达到最大值，这样更接近真实场景。
2、至于样本数的 failture，就是报的 connection time out
说明网络连接存在问题。
4、还有应用的 jvm 参数已经改过，相应增大到 2048m 没什么不一样，还是会出现这样 “暂停” 情况。所以当时就排除是应用 JVM 的问题。
你这个只是改了内存，jvm 还有很多参数的。比较明显影响并发性能的还有最大线程数。
5、后面做了测试，如果不使用域名进行压测的话，是不会出现样本数 “暂停” 的情况。直接对 IP 进行压测，不走 nginx 域名，直接压 ip，没什么问题。所以定位到 nginx 相关的一些配置问题，但修改 nginx 的性能配置还是没生效。目前还在调试排查中...
hmm，这方面信息超出你正文内容范畴了，没法给更好的建议，和运维保持沟通吧。