Gatling的性能测试对HTTP连接池进行精细配置是模拟真实负载、提升测试效率以及准确评估系统性能的重要步骤。maxConnectionsPerHost 和 maxQueueLength 是两个直接影响并发行为和资源管理的参数。

参数详解

maxConnectionsPerHost (每主机最大连接数)

这个参数限制了Gatling和单个目标主机（IP:端口对） 之间能够同时建立的最大HTTP连接数。

作用机制：当虚拟用户发出的请求超过当前活跃连接数时，Gatling会尝试建立新连接，直至达到此上限。此后的请求必须等待现有连接空闲或排队。

配置目的：防止测试客户端用过多连接压垮服务器，不符合真实用户的行为（浏览器对同一域名有连接数限制）。同时也是模拟不同浏览器/客户端行为、测试服务器连接管理能力的重要工具。

maxQueueLength (最大队列长度)

当所有到特定主机的连接都已用完，且新的请求到达时，这些请求不会立即被丢弃，而是进入一个等待队列。maxQueueLength 就控制着这个队列的最大容量。

作用机制：队列遵循先进先出（FIFO）原则。一旦有连接释放，队列中的第一个请求就会被取出执行。如果队列已满，新到达的请求将立即失败，一般会导致一个 java.util.concurrent.RejectedExecutionException。

配置目的：控制等待中的请求数量，避免在高压下无限制地堆积请求，导致测试客户端内存耗尽，并产生不现实的测试延迟。

配置方法

这两个参数需要根据你的协议类型和测试目标进行联合调整。

针对 HTTP/1.1 的配置：

HTTP/1.1 协议本身存在队头阻塞问题，浏览器一般允许对同一主机建立 6-8 个并发连接。在模拟这类客户端时，一般将 maxConnectionsPerHost 设置为 6至10 之间，以模拟真实场景。maxQueueLength 可以根据你希望允许的等待程度来设置，一般设置为一个合理的数值（如 100 或 1000），防止队列无限增长。

针对 HTTP/2 的配置：

HTTP/2 支持多路复用，允许在单个连接上并行交错传输多个请求和响应，彻底解决了HTTP/1.1的队头阻塞问题。在启用HTTP/2进行测试时，最好的方式是将 maxConnectionsPerHost 设置为 1。一个连接就足以承载高并发请求流，这更符合HTTP/2的优化特性，同时需要配合 .shareConnections 配置来让虚拟用户共享连接池。

代码示例

不同的测试目标需要不同的配置组合。以下是典型的配置代码：

scala

import io.gatling.core.Predef._

import io.gatling.http.Predef._

import scala.concurrent.duration._

class ConnectionPoolSimulation extends Simulation {

  // 场景一：模拟传统HTTP/1.1浏览器行为（例如，测试电商网站）

  val http1Protocol = http

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

    // 模拟Chrome浏览器对同一域名最多6个连接的行为

    .maxConnectionsPerHost(6)

    // 允许最多100个请求排队等待空闲连接

    .maxQueueLength(100)

  // 场景二：针对现代API服务的HTTP/2性能测试

  val http2Protocol = http

    .baseUrl("https://your-modern-api.zmtests.com")

    .enableHttp2 // 启用HTTP/2

    // HTTP/2下，一个连接足够多路复用所有请求

    .maxConnectionsPerHost(1)

    // 共享连接池，提升效率

    .shareConnections

    // 队列长度可以设置得较小，因为单个连接效率很高

    .maxQueueLength(50)

  val scn = scenario("测试场景")

    .exec(http("API请求").get("/endpoint"))

  // 使用不同的协议配置运行测试

  setUp(

    scn.inject(constantUsersPerSec(100).during(60.seconds))

  ).protocols(http2Protocol) // 或 http1Protocol

}

调优排查

配置后，需通过测试报告验证效果：

在Gatling的报告的“Response Time Distribution”和“Active Users vs Time”图表中，观察响应时间是否随用户数增长而平稳上升。如果出现断崖式增长，可能连接数或队列已满成为瓶颈。

检查报告中是否有连接超时或拒绝相关的错误。

可以通过调整参数，观察系统吞吐量（Requests/sec）和错误率的变化，找到当前测试场景下的最好的平衡点。