gatling不支持真正“无限等待”的websocket消息接收，但可通过大量预设的`await().on()`检查模拟长时间监听行为，结合循环动态生成检查逻辑，实现高保真压力测试。
在使用Gatling对基于WebSocket的实时推送系统进行压测时，一个常见需求是：客户端建立连接、发送订阅指令后，持续监听服务端推送（无固定结束时间），并统计单位时间内接收到的消息数量。遗憾的是，Gatling当前（v3.9+）的WebSocket DSL 不支持 forever 或无界等待语义——所有消息接收必须通过显式声明的 await(timeout).on(check) 形式定义，且检查次数需在编译期确定。
不过，这并不意味着无法模拟长连接监听场景。核心思路是：用足够多的有限次 await 检查覆盖预期测试时长，并辅以合理的超时与容错策略。例如，若目标测试时长为5分钟，平均消息间隔为2秒，则理论上最多接收150条消息；可预设200~300次检查，确保覆盖峰值流量。
以下是一个可复用的 Scala 示例，利用循环动态构建链式 WebSocket 操作：
import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._
class WebSocketLongPollingSimulation extends Simulation {
val httpProtocol = http
.baseUrl("https://your-api.example.com")
.acceptHeader("application/json")
val scn = scenario("WebSocket Long-Listen Scenario")
.exec(
// 1. 建立 WebSocket 连接
ws("Connect to WS")
.connect("/ws/events")
)
.exec(
// 2. 发送订阅消息（如 JSON）
ws("Subscribe to topic")
.sendText("""{"action":"subscribe","topic":"notifications"}""")
)
// 3. 动态生成 250 次 await 检查（覆盖约 6–10 分钟常规负载）
.exec(
(1 to 250).foldLeft[ChainBuilder](empty) { (chain, i) =>
chain.exec(
ws(s"Wait for message #$i")
.await(30.seconds) // 单次最长等待30秒，避免卡死
.on(
wsCheck("Validate message format")
.check(wsJsonPath("$.event").exists)
.check(wsJsonPath("$.timestamp").is(not(null)))
)
)
}
)
setUp(scn.inject(atOnceUsers(100))).protocols(httpProtocol)
}⚠️ 关键注意事项：
- await 超时值需谨慎设置：过短（如
- 检查逻辑应轻量且精准：避免复杂正则或嵌套校验，优先使用 wsJsonPath 或 wsRegex 提升性能。
- 不建议盲目堆叠万级检查：Gatling 会将所有 await 编译为状态机节点，过多检查可能增加内存开销。实际中 200–500 次已能有效模拟“长监听”行为。
- 消息速率度量需额外处理：Gatling 默认不统计“接收频次”，建议在 wsCheck 中通过 transform 提取时间戳，或配合后端日志/监控（如 Prometheus + Grafana）做端到端吞吐分析。
综上，虽然 Gatling 无法字面意义实现“forever listen”，但通过合理设计检查密度、超时策略与数据验证粒度，完全可构建高可信度的 WebSocket 长连接压测场景，精准评估服务端在持续推送压力下的稳定性与吞吐能力。
