Gatling高用户量加压时遭遇io.netty.channel.ConnectTimeoutException异常

问题背景 #

我需要对API进行高负载测试，编写的Gatling负载配置如下：

setUp(
    scn.inject(
      nothingFor(2 seconds),
      constantUsersPerSec(250) during (300 seconds),
      rampUsersPerSec(50) to (100) during (60 seconds),
    ).protocols(httpConfig)

测试中遇到以下问题：

• 仅用250用户持续加压300秒时，出现大量错误
• 期望生成每秒1000次API调用，但监控显示仅能达到约200次/秒
• 目标是5-10分钟内完成50万次调用，目前仅能完成5-7万次且报错
• 已尝试结合constantUsersPerSec与rampUsersPerSec配置，但未解决问题

核心问题分析 #

1. 用户数与请求数不匹配：250用户每秒只跑出200次请求，说明单用户每秒请求数（RPS）才0.8次，远低于预期，要么是请求响应时间太长，要么是客户端配置限制了并发能力
2. 错误拖垮有效请求：大量错误会占用客户端资源，导致有效请求上不去，得先搞清楚是超时、连接失败还是服务端报错
3. 负载注入太激进：直接瞬间压250用户，可能超出客户端或服务端的初始承受能力，直接雪崩了

优化方案 #

1. 先揪出错误根源 #

• 查Gatling日志，明确错误类型：是连接超时、请求超时，还是服务端返回5xx/4xx？
• 看服务端监控：CPU、内存、数据库连接池、线程池是不是满了，有没有资源瓶颈

2. 调优客户端配置 #

• 优化httpConfig的连接参数，提升并发能力：

  val httpConfig = http
    .maxConnectionsPerHost(100) // 提高单域名并发连接数
    .connectionTimeout(5 seconds)
    .requestTimeout(10 seconds)
    .userAgentHeader("Gatling/LoadTest")
  

• 调整Gatling线程池：默认线程数可能不够，改gatling.conf里的akka.actor.default-dispatcher.thread-pool-executor.core-pool-size-min等参数，增加可用线程

3. 改负载注入策略，逐步加压 #

• 别直接怼250用户，先逐步升上去，给系统缓冲时间：

  setUp(
    scn.inject(
      nothingFor(2 seconds),
      rampUsersPerSec(50) to (250) during (120 seconds), // 2分钟逐步升到250用户
      constantUsersPerSec(250) during (240 seconds), // 稳定压4分钟
      rampUsersPerSec(250) to (100) during (60 seconds) // 测试结束前逐步降载
    ).protocols(httpConfig)
  

• 算清楚需要多少用户：如果单用户每秒能发4次请求，1000 RPS就需要250用户；要是单用户RPS低，得先优化API本身的响应速度

4. 先测单用户性能 #

• 先跑1个用户的测试，看看单用户每秒能发多少次请求，响应时间是多少
• 如果单用户RPS低，查API本身：有没有慢SQL、外部依赖调用超时之类的问题

5. 分布式压测 #

• 单台机器跑不出目标RPS的话，用Gatling分布式模式，多台机器一起压

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