使用JMeter通过AWS负载均衡器压测时遇连接超时问题

1. 核查AWS负载均衡器（LB）的限制与状态 #

• 查看LB的每秒新建连接数（CPS）配额，AWS默认配额可能无法支撑10000并发/秒的突发请求。通过CloudWatch指标NewConnectionCount确认是否触及上限，若达到配额需提交工单提升。
• 检查CloudWatch中的TargetResponseTime和UnHealthyHostCount指标，确认是否存在后端实例健康检查失败，导致LB无法正常转发请求引发超时。
• 确认LB的空闲连接超时设置（默认60秒），若JMeter未配置连接复用，会导致频繁新建TCP连接，加重LB负载。

2. 优化JMeter压测配置 #

• 启用HTTP连接复用：在HTTP请求默认值中开启Use keepalive，添加Connection: keep-alive请求头，减少TCP握手开销。同时调整jmeter.properties配置：

  httpclient4.retrycount=1
  httpclient4.idletimeout=60000
  

• 提升压测机资源配置：10000并发线程对CPU、内存、网络要求极高：
  • 确保压测机有16核以上CPU，关闭swap分区，设置JMeter堆内存为HEAP="-Xms8g -Xmx16g"
  • Linux系统执行ulimit -n 65535提升文件描述符限制，Windows修改注册表调整句柄数
• 采用分布式压测：单台机器难以支撑10000并发，用JMeter分布式模式，多台压测机分摊负载，避免单节点资源瓶颈。

3. 排查后端服务瓶颈 #

• 检查EC2/ECS/EKS实例的CPU、内存、磁盘IO使用率，确认是否触及资源上限。
• 查看后端服务日志，排查是否存在线程池耗尽、数据库连接池不足等情况，导致无法处理新请求。
• 验证数据库、缓存等依赖服务的性能，确认其能支撑10000QPS的请求量。

4. 调整压测策略（不降低并发需求） #

• 改用阶梯式加压：比如前3秒每秒加2000用户，中间4秒每秒加1500用户，最后3秒加剩余用户，给LB和后端服务预热时间，避免突发流量直接打垮系统。
• 启用JMeter延迟线程创建：在jmeter.properties中设置threads.startup_delay=true，减少初始内存占用，避免压测机启动时资源耗尽。

错误java.net.SocketException本质是TCP连接建立失败，要么是LB/后端无法及时响应SYN包，要么是压测机自身资源不足无法发起连接。

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