Postman传输启动时长与API Gateway日志集成延迟差异问询

问题背景 #

用Postman测试某API端点时，Postman显示传输启动时长为1271.98ms，超出预期；但查看该请求的CloudWatch日志，API Gateway的集成延迟仅为62ms。已知Postman的传输启动时长不含DNS查询、TCP/SSL握手环节，且端点处理速度极快，对二者的巨大差异存在疑惑，原本预期二者时长一致。

可能的差异原因 #

• API Gateway延迟统计范围有限：集成延迟仅统计API Gateway向后端服务转发请求并收到响应的时间，而API Gateway处理请求的完整流程还包括请求接收、认证/授权、请求转换、响应转换等环节，这些步骤的耗时不在集成延迟统计范围内，但会被计入Postman的传输启动时长。
• 客户端到API Gateway的网络耗时：Postman的传输启动时长是从客户端发送请求到收到第一个响应字节的总时间，其中包含了请求从本地客户端传输到API Gateway服务器的网络延迟（尤其是跨区域请求时，这部分延迟会很明显），而这部分时间不会体现在API Gateway的集成延迟里。
• API Gateway队列等待时间：如果API Gateway处于高负载状态，请求可能会进入内部队列等待处理，这部分等待时间属于API Gateway总延迟，但不会被统计到集成延迟中，却会被Postman计算在传输启动时长内。
• 时间统计的起点/终点差异：
  • CloudWatch集成延迟的起点是API Gateway准备转发请求到后端的时刻，终点是收到后端响应的时刻
  • Postman传输启动时长的起点是客户端发出请求的第一个字节，终点是收到响应的第一个字节，中间涵盖了请求传输到API Gateway的时间、API Gateway前置处理时间，这些都不在集成延迟的统计范畴内

排查建议 #

• 在Postman控制台开启请求的详细耗时拆分，定位具体耗时环节
• 查看CloudWatch中API Gateway的Latency指标（总延迟，包含集成延迟和API Gateway自身处理时间），对比该指标与Postman的传输启动时长，判断差异来源
• 尝试在API Gateway所在区域的服务器发起请求，排除跨区域网络延迟的影响

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