评估 API 延迟时应检查哪些内容？
什么是 API 延迟，以及为何评估不止于一个数字
API 延迟是指客户端与 API 之间完成一次交互所需的时间。在实践中，通常以端到端时间（例如，从请求到响应）来讨论，但“端到端”视图可能包含多个不同阶段：DNS 查询、TCP/TLS 握手（如果未复用）、网络传输、服务器处理，以及因排队或速率限制而产生的任何等待时间。
有效的评估应将稳定机制（系统在特定条件下的行为）与可变条件（网络拥塞、提供商负载和需求变化）区分开来。这一点很重要，因为两个系统可能表现出相似的“平均延迟”，但在最坏情况下的延迟或故障行为却可能完全不同。
为了遵循尽职调查的方法，你还应明确你的假设。如果你在比较不同提供商，需定义你使用的时间窗口、发送的请求类型，以及是在客户端测量还是在你的基础设施内部测量。
实证检查清单：在解读延迟前应测量什么
使用以下控制检查清单，以可独立验证的方式评估延迟：
- 明确测量定义
- 询问延迟是在客户端、服务器端测量，还是作为建模值。
- 确认“时间”包含哪些内容：网络、应用处理和重试。
- 将延迟分解为多个阶段 即使提供商报告的是单一指标，也应尝试观察与阶段相关的线索：
- 连接建立与复用（新连接可能增加握手开销）。
- 排队或节流迹象（无处理的长时间延迟可能表示等待）。
- 载荷大小的影响（较大的响应可能增加序列化和传输时间）。
- 使用多个百分位数和失败计数 平均延迟可能掩盖不稳定性。应跟踪百分位数（例如，较高百分位数），并记录：
- 超时和错误率。
- 重试行为及任何退避策略。
- 异常值：延迟超过你设定阈值的频率。
- 使用真实请求模式进行测试 延迟取决于流量模式。使用一致的工作负载：
- 你实际会调用的消息类型。
- 并发级别。
- 相对于任何公布的吞吐量限制的请求速率。
- 记录环境和可重复性 为使比较有意义，需记录：
- 客户端位置/区域和路由路径假设。
- 测试持续时间和时间点。
- 是否使用了预热连接或冷启动。
小示例（含明确假设）
假设你的客户端在发送请求和接收到完整响应的时刻测量请求到响应的时间。如果提供商 A 的超时次数少于提供商 B，但偶尔出现大幅延迟峰值，则“平均”延迟可能相似，但实际用户体验却不同。因此，你应在相同的并发和请求模式下，比较较高百分位延迟和超时频率。
现实世界中的运作：稳定机制 vs. 可变条件
在实际延迟行为中，两种稳定机制通常占主导地位：
- 负载下的排队：当服务器或中间件繁忙时，请求可能在处理前等待。即使平均处理时间稳定，这也可能导致延迟急剧上升。
- 速率限制和节流：如果请求超过限制，系统可能会延迟、拒绝或要求重试。这些行为会显著改变端到端时间。
可变条件包括：
- 网络拥塞和路由变化。
- 提供商资源竞争（CPU、I/O、数据库访问或下游依赖）。
- 你调用的任何下游逻辑中的市场相关变化（例如，你的请求如何映射到内部工作流）。
由于这些因素会变化，历史关系并不能保证未来结果。即使你上个月测得延迟良好，也应将其视为一次观察，而非承诺。
需注意的限制与风险
在“仅看延迟”的评估中，至少有一项重要限制常被忽视：
-
延迟与结果的关联并非自动成立 即使延迟较低，如果可靠性、正确性或故障处理较弱，仍可能导致更差的结果。相反，如果失败罕见且响应一致，稍高的延迟也可接受。
-
最坏情况行为往往是真正风险 一个偶尔出现严重延迟峰值的系统可能存在问题。这就是为什么超时、重试风暴和尾部延迟至关重要。
-
重试可能增加端到端时间 如果你的客户端自动重试，单个慢请求可能变成多次尝试，使实际延迟更长且更不可预测。
-
不同定义可能导致比较误导 提供商可能报告处理时间，而你测量的是端到端时间。这两者并不相同，因此必须统一定义。