负载测试响应时间过高但Load Generator及应用服务器无资源饱和求助

这是负载测试里挺典型的「资源不饱和但响应时间飙升」的问题，我帮你梳理几个核心排查方向，都是实际工作中踩过的坑：

首先先明确你的问题场景：

采用Web/HTTP脚本、25用户负载开展测试，所有事务的响应时间从爬坡阶段的5秒逐步攀升至稳定阶段的90秒以上。但Load Generator资源利用率低于20%，应用层资源利用率不足10%，CPU、内存、磁盘及线程均未出现资源饱和情况。在稳定阶段，直接在Load Generator机器上运行Vugen脚本时，响应时间低于5秒。

1. 先查LoadRunner的负载调度配置 #

有时候表面设了25个用户，但Controller可能没把并发请求真正发出去，或者存在内部调度瓶颈：

• 确认Runtime Settings里的运行模式：是Run Vuser as a thread还是进程模式？进程模式开销更大，但这里资源没满，重点看线程模式下的调度限制，比如Load Generator的最大线程数是否被系统限制了？
• 实时查看Controller的Vuser Status面板：确认25个用户是不是都处于Running状态，有没有Pending/Ready的用户卡在调度环节。
• 检查Pacing设置：如果设置了过长的思考时间或者固定等待时间，可能会导致请求堆积，但更要注意是否有请求在Load Generator的发送队列里排队——可以用LoadRunner的自带监控查看Generator的请求发送速率。

2. 排查网络链路的隐性限流/瓶颈 #

虽然Generator和应用服务器资源都空着，但中间网络可能卡了：

• 测试期间持续监控Generator到应用服务器的网络：用ping -t（Windows）或者ping -i 0.1（Linux）看延迟波动，用iperf测带宽，排查是否有丢包、延迟突增的情况。
• 检查防火墙/负载均衡器的限流策略：很多设备会对同一IP的并发请求数、请求频率做限制，Controller调度时所有Vuser用Generator的IP发请求，容易触发限流；但直接跑Vugen时请求量小，不会触发这个限制。
• 查看应用服务器的TCP连接状态：用netstat -an（Windows）或者ss -s（Linux）看TIME_WAIT/ESTABLISHED连接数，如果连接堆积过多，会导致新请求无法及时建立连接，拖慢响应时间。

3. 对比Vugen与Controller的运行环境差异 #

直接跑Vugen和通过Controller调度的脚本，运行环境可能不一样：

• 核对脚本版本与Runtime Settings：确认Controller里的脚本是不是和Vugen本地的一致，有没有在Controller里修改过思考时间、日志级别、代理设置（比如不小心开了代理）。
• 检查会话复用情况：Vugen本地跑的时候可能复用了浏览器缓存、会话Cookie，而Controller里每个Vuser都是独立初始化会话，服务器需要处理更多会话创建逻辑——虽然25个用户不多，但如果服务器会话初始化开销大，也会累积延迟。
• 调低Controller的日志级别：如果开了详细日志（比如Extended Log），Generator会花时间写日志，虽然资源利用率显示低，但IO可能有隐性瓶颈，调低日志级别再测一次。

4. 深挖应用层的隐性瓶颈 #

应用CPU、内存没满，不代表没有性能瓶颈：

• 查数据库层面：应用服务器资源空着，可能是在等数据库响应。查看数据库的慢查询日志、锁等待状态，稳定阶段是不是出现了大量慢查询或者锁冲突？
• 检查连接池/线程池配置：应用的HTTP线程池、数据库连接池如果设置过小，请求会排队等资源，导致CPU空闲但响应时间飙升——比如Tomcat的maxThreads设置得太低，数据库连接池maxActive不够。
• 排查缓存失效：爬坡阶段缓存是热的，稳定阶段缓存过期或者被清空，大量请求直接打数据库，导致响应时间暴涨。

内容的提问来源于stack exchange，提问作者jaysel