SaaS API 地区延迟基线怎么建？请求口径与分位数

报告分位数并保留样本量：p50 描述中位响应，p95 反映较慢请求，p99 仅在样本足够时参考。可比性取决于接口、客户端、负载和采样窗口一致，不存在适用于所有接口的固定请求数。本文测的是自有 API 的应用响应，不是代理网络本身的延迟与稳定性。

先定分位数和判读口径

一个接口的平均响应时间可能掩盖尾部慢请求，因此基线通常还要报告分位数。p50 表示中位响应，p95 和 p99 描述分布尾部；同时应提供样本量、窗口、错误率和计算方法，避免只凭几个数字下结论。

示例：若 p50 稳定而 p95 明显升高、错误率变化不大，可先检查慢请求是否集中在特定时段、请求类型或下游依赖，再结合重试和连接复用记录判断。

跨窗口比较时不要直接平均分位数

不能直接平均各窗口的分位数。总体分位数需要原始样本，或同一口径、兼容且可合并的分布数据，例如直方图或相应摘要；只有各窗口的 p95 时，不能重算总体 p95。固定窗口可用于逐窗比较，但不能恢复已经丢失的分布。使用分桶时应注明算法与精度。保留原始请求耗时是可行方案之一，并非唯一方案。

稳定与否要看窗口之间的波动，不看单窗口的数字。每窗口记录样本量、p95 与错误率；连续几个窗口的 p95 偏差落在预设范围内、样本量达到目标，才可宣称基线稳定，否则标为暂定并在结论中写明适用窗口。

先明确延迟基线测量了哪些环节

基线要回答的是“用户在这个地区调用我的接口，多久能看到响应”。采样前固定测量单位和起止点：明确统计首字节（TTFB）还是完整响应体，并说明是否包含 DNS、建连、TLS、连接复用和客户端等待。它反映应用、客户端和测试网络共同作用下的观测结果；若要判断具体阶段，应在相应观测点分别采集，不能随意相加或相减来认定纯网络耗时。

固定影响可比性的条件

固定请求体或明确区分请求类型与请求大小（含上传/下载体积），记录测量起止点、是否含 DNS/建连/TLS、连接复用、客户端等待、采样时段、并发、客户端版本和缓存状态；不同地区使用可比的测试端与请求路径，避免把负载差异当成地区差异。

分开记录预热请求与缓存命中结果

预热请求应单独标记，不要不加说明地混入稳态样本或直接剔除。记录剔除规则和数量；带缓存的接口还要区分命中与未命中，避免不同请求路径混在一起。测量应用响应时，应分别记录服务端处理、客户端和网络耗时。

按统一口径建立并复核基线

1. 定接口与请求内容，记录请求体或参数，并确保测试不会修改真实用户数据。产出：接口与请求说明。
2. 定测试地区与发起端，尽量保持客户端、版本和负载可比。产出：地区与客户端清单。
3. 按目标分位数和流量波动确定采样量，记录预热请求及剔除理由。产出：可复核的原始样本。
4. 按固定算法计算 p50、p95、适用时的 p99、错误率与限流占比。产出：一期统计结果。
5. 在可比窗口复测，并根据业务周期评估基线稳定性。产出：注明适用范围和限制的基线。若这套基线用于地区发布观测，可将窗口和分组口径接入地区灰度验证，但仍需单独定义发布动作和回滚条件。

对照服务端、客户端和网络指标分析波动

延迟波动可能来自服务端排队、网络、客户端负载、缓存或重试。按一次请求尝试还是含重试的逻辑请求统计应预先定义；成功耗时、HTTP 错误和无响应超时分别记录。先按地区和版本拆分数据，再结合服务端监控、客户端日志和请求标识归因；地区差异不能直接等同于网络或代理差异。

FAQ

每地区多少样本才够报 p95？

没有通用固定值。样本不足以稳定估计 p95 时，应继续采样或把结果标为暂定。

预热请求要不要计入稳态基线？

先按目标区分冷启动和稳态结果；若剔除预热请求，注明规则和剔除数量。

被限流的请求要不要计入延迟？

将 429 与成功请求分开统计，并同时报告限流数量和占比。

不同地区的 p95 可以直接取平均吗？

不建议。总体分位数需基于原始样本或兼容、可合并的分布数据重新计算；仅有各地区的 p95 无法还原总体 p95。若使用固定窗口，只能按窗口比较。