在Gatling中，connectionTimeout 和requestTimeout是控制网络请求行为的重要超时设置，超时设置作用于请求的不同阶段。
1. connectionTimeout
connectionTimeout 定义了从尝试发起TCP连接到成功建立连接所允许的最长时间。它主要涵盖了TCP三次握手及可能的SSL/TLS握手时间。
配置：
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定义了从发送请求开始，到完整接收到响应体为止的总时间上限。包括了连接建立、请求发送、服务器处理和网络传输回来的整个过程。
配置：
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分钟。请在全局协议和单个请求两个层面灵活配置。
文章来源：卓码软件测评
精彩推荐：点击蓝字即可
▲软件负载测试▲API自动化测试▲软件测试▲第三方软件测试▲软件性能测试▲软件测试机构
配置调试
1. 分层配置
Gatling的超时配置具有层次性，优先级从高到低为：单个请求 > 场景/协议组 > 全局协议。
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. 结合检查点进行故障诊断
利用超时和检查点，可以精确区分不同类型的性能问题。
.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、内存、线程池使用率、慢查询日志）进行关联分析。
