Gatling异步处理中OK/KO判定逻辑优化问题咨询

方案1：延迟结果判定，基于Session关联业务时间戳 #

• 改造现有自定义Action：仅负责发送输入请求，将消息唯一key和startTime存入Gatling Session，直接放行虚拟用户流程（不立即标记OK/KO）。
• 调整Kafka/JMS监听器逻辑：收到输出消息后，通过key匹配对应Session，计算endTime - startTime判断业务是否超时，再通过Session API更新该请求的最终状态（OK/KO）及业务耗时。
• 配置Gatling会话超时：调大gatling.http.ahc.sessionTimeout参数，确保Session生命周期覆盖最长业务处理时长，避免提前回收导致状态无法更新。
• 自定义统计收集：在Simulation类中添加钩子，定期从Session汇总延迟判定的结果，纳入最终测试报告。

方案2：扩展Gatling Check机制，实现事件驱动的结果校验 #

• 实现自定义AsyncBusinessCheck：继承Gatling的Check接口，注册监听器回调而非阻塞等待。
• 发送请求时：将key和startTime传入Check，Check仅完成回调注册，直接返回会话成功，不阻塞虚拟用户。
• 监听器触发回调：收到对应key的消息后，计算业务耗时并判定超时，再更新会话中的请求状态。

示例代码片段（Scala）：

import io.gatling.core.check.Check
import io.gatling.core.session.Session
import scala.util.Success

class AsyncBusinessCheck(key: String, startTime: Long, timeoutThreshold: Long) extends Check[Session] {
  override def check(session: Session, response: Any): Validation[Session] = {
    // 注册监听器回调
    MessageCallbackRegistry.register(key, (endTime: Long) => {
      val duration = endTime - startTime
      val status = if (duration <= timeoutThreshold) "OK" else "KO"
      // 更新会话中的请求状态
      session.set(s"req_$key", status)
    })
    Success(session)
  }
}

• 在自定义Action中使用该Check：替代原有的异步等待逻辑，让请求状态由业务实际处理结果驱动。

方案3：分离发送与校验流程，独立统计业务性能 #

• 发送阶段：用Gatling虚拟用户批量发送输入请求，将key和startTime存入Redis等外部存储，此阶段仅统计发送成功率和TPS，所有请求标记为OK。
• 校验阶段：独立运行校验程序，监听Kafka/JMS输出，通过key从外部存储获取startTime，计算业务耗时并判定超时，生成独立的业务性能报告。
• 可选整合：若需在Gatling中展示结果，可在虚拟用户后续步骤中轮询外部存储的校验结果，但需避免轮询逻辑影响发送阶段的TPS统计。

内容的提问来源于stack exchange，提问作者Julian