gatling不支持真正的“无限接收”websocket消息，但可通过大量预设的await检查模拟长时间监听行为，结合循环生成检查点，实现对服务端推送频率与客户端接收能力的量化压测。
在使用Gatling进行WebSocket性能测试时，一个常见需求是模拟真实业务中客户端建立长连接后持续监听服务端推送（如事件通知、实时消息等）的行为。然而，Gatling的WebSocket DSL设计为声明式、有限状态驱动，其核心限制在于：ws.await() 必须绑定明确数量的预期消息检查（check），不支持 forever 或无界等待语义。
例如，以下写法是非法且不可行的：
// ❌ 错误示例：Gatling不识别 forever
exec(ws("Listen").await(30).forever.on(wsCheckMessage))✅ 正确做法是：用固定但足够大的迭代次数替代“永久监听”。假设你期望单个虚拟用户（VU）在5分钟内接收约10,000条推送消息（平均1条/30ms），可构造如下结构：
Session Handoff
下载
创建全面的交接文档，使新AI代理能够无缝继续工作，消除歧义。解决上下文耗尽问题。 时机：(1)用户请求保存交接，(2)上下文即将满，(3)主要任务完成，(4)会话结束，(5)恢复工作时。 关键词：保存状态、创建交接、上下文已满、暂停、从...恢复、加载交接、保存进度、会话转移、交接
def generateWsChecks(count: Int): Seq[WsCheckBuilder[_]] = {
(1 to count).map { i =>
wsCheck(s"ws_check_$i")
.check(wsJsonPath("$.type").ofType[String].saveAs(s"msg_type_$i"))
.check(wsJsonPath("$.timestamp").ofType[Long].saveAs(s"ts_$i"))
}.toSeq
}
val checks = generateWsChecks(10000)
exec(ws("Connect").connect("/ws"))
.exec(ws("Subscribe").sendText("""{"action":"subscribe","topics":["news","alerts"]}"""))
.exec(
checks.zipWithIndex.map { case (check, idx) =>
ws(s"Receive_Msg_$idx").await(60).on(check)
}.reduce(_ andThen _)
)⚠️ 关键注意事项：
- 内存与性能权衡：生成10,000个await检查会显著增加JVM堆内存占用和初始化时间，建议根据压测目标（如最大持续时长、预期吞吐量）合理设定上限（如3000–5000次）；
- 超时策略：每个.await(N)表示最多等待N秒接收一条消息；若服务端推送延迟或中断，该步骤将失败并终止当前用户链路，因此需配合retry或容错逻辑（如tryMax(3)）提升鲁棒性；
- 指标采集：利用wsCheck中的saveAs保存每条消息元数据，后续可通过session.get[String](...)在自定义计数器或日志中统计接收速率、延迟分布等；
- 真实感增强：可结合pace(100.milliseconds)或asLongAs(session => session.get[String]("status") == "active")实现动态条件循环（需配合自定义ActionBuilder），但底层仍需预设退出边界。
总结而言，Gatling虽无法字面意义实现“永远监听”，但通过高密度预设检查 + 合理超时 + 结构化数据捕获，完全可构建高保真WebSocket长连接压测场景，精准衡量服务端消息分发能力与客户端端到端接收稳定性。
