在Gatling中，connectionTimeout 和requestTimeout是控制网络请求行为的重要超时设置，超时设置作用于请求的不同阶段。

1. connectionTimeout

connectionTimeout 定义了从尝试发起TCP连接到成功建立连接所允许的最长时间。它主要涵盖了TCP三次握手及可能的SSL/TLS握手时间。

配置：

scala

import io.gatling.core.Predef._

import io.gatling.http.Predef._

val httpProtocol = http

  .baseUrl("http://api.zmtests.com")

  // 重点：连接超时设置（通常建议1-5秒）

  .connectionTimeout(3000) // 单位：毫秒，此处设为3秒

  .requestTimeout(10000)   // 请求超时设为10秒

// 场景：测试网络不稳定或服务器无响应时的表现

val scn = scenario("测试连接超时")

  .exec(

    http("请求可能无法到达的服务")

      .get("/endpoint")

      // 此请求将在尝试连接3秒后失败

  )

触发场景：

目标服务器宕机或端口未开放。

网络严重拥塞或防火墙阻断了连接。

服务器负载极高，无法及时接受新的连接。

值设置过短，在慢速网络（如移动网络）下易误判。

建议：此值通常设置为 1至5秒。在内网测试中可设为1-2秒；对公网或移动网络测试，建议3-5秒或更长。

2. requestTimeout

requestTimeout定义了从发送请求开始，到完整接收到响应体为止的总时间上限。包括了连接建立、请求发送、服务器处理和网络传输回来的整个过程。

配置：

scala

val httpProtocol = http

  .baseUrl("http://api.zmtests.com")

  .connectionTimeout(3000)

  // 重点：请求总超时设置

  .requestTimeout(15000) // 全局设置为15秒

val scn = scenario("测试不同接口的请求超时")

  .exec(

    http("快速查询接口")

      .get("/fast-query")

      // 可针对单个请求覆盖全局设置

      .requestTimeout(2000) // 此接口期望2秒内响应

  )

  .exec(

    http("慢速报表生成接口")

      .get("/slow-report")

      .requestTimeout(60000) // 此复杂操作允许60秒

  )

触发场景：

服务器处理逻辑复杂、耗时过长（如复杂计算、大数据查询）。

服务器发生死锁或性能故障。

网络链路延迟高或带宽不足，导致大型响应体下载缓慢。

客户端和服务器之间的长停顿。

建议：值需根据业务接口的SLA（服务水平协议） 设定。常规API可设为5-15秒；批处理或文件导出接口可能需要1-5分钟。请在全局协议和单个请求两个层面灵活配置。

配置调试

1. 分层配置

Gatling的超时配置具有层次性，优先级从高到低为：单个请求 > 场景/协议组 > 全局协议。

scala

val customTimeoutHttpProtocol = http

  .baseUrl("http://api.zmtests.com")

  .connectionTimeout(5000)

  .requestTimeout(30000) // 全局基准：30秒

val scn = scenario("分层超时配置")

  .exec(

    http("首页")

      .get("/") // 继承全局的5秒连接超时和30秒请求超时

  )

  .exec(

    http("上传大文件")

      .post("/upload")

      .requestTimeout(120000) // 单独覆盖：上传允许2分钟

  )

2. HTTP/2和WebSocket

HTTP/2：由于连接复用，connectionTimeout 在连接池中有可用连接时可能不生效。但requestTimeout仍然对每个独立的请求/响应流有效。

WebSocket：requestTimeout不适用于WebSocket帧的传输。一般通过心跳机制或自定义逻辑来监控WebSocket连接的健康状态。

3. 结合检查点进行故障诊断

利用超时和检查点，可以精确区分不同类型的性能问题。

scala

.exec(

  http("关键事务")

    .post("/transaction")

    .requestTimeout(5000)

    .check(

      status.is(200), // 检查HTTP状态码

      responseTimeInMillis.lt(3000) // 检查响应时间是否小于3秒

    )

)

// 在结果报告中，可以区分：

// 1. 因超时失败的请求（RequestTimeoutException）

// 2. 响应慢但未超时的请求（通过responseTime检查发现）

// 3. 返回错误状态码的请求

4. 在报告中监控超时

Gatling的HTML报告不会直接列出超时请求数，但可以通过以下方式查找：

查看响应时间分布：如果大量请求堆积在接近超时阈值的区间，说明系统处于临界状态。

分析错误标签页：由超时引起的请求失败，一般会被归类为RequestTimeoutException或ConnectionTimeoutException。

总结

区分connectionTimeout（网络连通性）和requestTimeout（业务处理能力）的不同。

不要使用“一刀切”的超时值。为快速查询接口、慢速报表接口、文件上传接口等设置不同的requestTimeout。

在局域网中可使用更短的超时以快速暴露问题；对公网或移动网络测试，必须适当放宽超时，避免因正常网络波动导致大量测试失败。

故意将超时设置得非常短（如100ms），用于测试系统在极端情况下的降级和容错能力。

将Gatling测试中观测到的超时情况，和服务器的监控指标（如CPU、内存、线程池使用率、慢查询日志）进行关联分析。