通过AWS负载均衡器用JMeter测试API时遇504及CPU100%问题

这个场景我之前踩过坑，咱们从几个核心方向拆解排查：

1. 连接复用与LB的TCP配置不匹配 #

AWS ALB/NLB默认的TCP空闲超时（Idle Timeout）是60秒，而JMeter默认可能没开启HTTP Keep-Alive，或者连接复用设置不对，导致LB为每个JMeter请求创建新的TCP连接。当并发上来时，后端实例要处理大量的TCP握手/挥手操作，直接把CPU拉满，进而触发LB的504超时（因为后端没及时响应）。

解决步骤：

• 在JMeter的HTTP请求Sampler里，勾选「Use Keep-Alive」选项，让请求复用TCP连接；
• 调整AWS LB的Idle Timeout，比如设为120秒（和JMeter的连接保持时间匹配）；
• 检查JMeter的httpclient4.retrycount和httpclient4.idletimeout等配置，确保和LB的设置兼容。

2. 请求头差异触发后端异常逻辑 #

Postman和JMeter发送的请求头往往不一样——比如JMeter默认的User-Agent是Apache-HttpClient/4.5.13 (Java/1.8.0_301)，而Postman是自己的UA。有些后端服务会针对特定UA做特殊处理（比如反爬校验、额外的计算逻辑），或者对缺失的头字段处理不当，导致CPU飙升。

解决步骤：

• 用抓包工具（比如Wireshark、Charles）分别捕获Postman和JMeter的请求，对比两者的请求头；
• 在JMeter的HTTP请求头管理器里，完全复刻Postman的请求头（包括User-Agent、Accept、Content-Type等），再测试看是否还会出现问题。

3. JMeter的并发/请求模式过载后端 #

Postman是单请求或低频率请求，而JMeter是批量并发请求，如果你的线程组配置不合理（比如Ramp-Up Period设为0，瞬间启动所有线程），后端实例会被瞬间压垮，CPU直接打满，LB就会返回504。

解决步骤：

• 先降低并发数测试：比如先开1个线程跑，看是否正常；如果正常，再逐步增加线程数，找到后端能承受的阈值；
• 调整Ramp-Up Period：比如100个线程设为100秒，每秒启动1个线程，让后端有时间逐步处理请求；
• 检查JMeter的定时器：比如如果用了Constant Timer设置间隔太小，或者有自定义的前置处理器做大量计算，也会间接导致请求频率过高。

4. AWS LB的流量分发与健康检查问题 #

有时候LB的健康检查配置太宽松，当后端CPU已经100%时，LB还没检测到实例异常，继续把请求分发过去，形成恶性循环。或者LB的分发算法是轮询，但某个实例性能较差，导致所有请求都压在它上面。

解决步骤：

• 查看AWS CloudWatch的LB指标：比如TargetResponseTime、HTTPCode_Target_5XX_Count，对应测试时间段的数据；
• 调整LB的健康检查配置：缩短健康检查间隔（比如从30秒改成10秒），调低健康阈值，让LB更快发现异常实例并停止分发；
• 切换LB的分发算法：比如从轮询改成「最小连接数」，让请求优先分发到空闲的实例。

5. 后端服务的资源配置瓶颈 #

后端实例的线程池、JVM内存等配置可能不足以应对JMeter的并发请求。比如Tomcat的maxThreads设得太小，导致请求排队，CPU因为上下文切换频繁而飙升；或者JVM堆内存不足，频繁触发Full GC，占用大量CPU。

解决步骤：

• 检查后端服务的线程池配置：比如Tomcat的server.xml里的maxThreads，适当调大（比如从200改成500）；
• 调整JVM参数：增大堆内存（比如-Xmx4G -Xms4G），减少GC频率；
• 查看后端实例的CloudWatch指标：CPUUtilization、GCUtilization、RequestCount，定位具体的瓶颈点。

快速验证步骤 #

1. 用JMeter单线程测试：如果正常，说明是并发量或请求模式的问题；
2. 查看LB的访问日志：找到返回504的请求，对应到具体的后端实例，确认该实例的CPU是否在当时达到100%；
3. 直接用JMeter访问后端实例（绕开LB）并逐步增加并发：如果此时CPU也会打满，说明后端本身的性能瓶颈，和LB无关；如果绕开LB后正常，那问题肯定出在LB和JMeter的交互上。

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