延迟预算：p95 目标与「平均值骗人」

2026/9/20

背景与问题

「服务器不慢」的感觉常被平均值掩盖——p95/p99 才是用户体感。solo 后端给 API 定延迟预算（latency budget）的最小做法：设多少、怎么测、超了怎么办。

（来源访问日期均为 2026-09-20 访问）

事实（Redis、Nirvana Labs）：平均值会隐藏最慢的用户——p95=95% 的请求在此以下完成，剩下的 5% 才是体感差评的来源。
事实（Nurbak 的目标基准）：对外 REST API p95 < 500ms、内部微服务间 p95 < 100ms 为常用目标。
事实（New Relic）：面向用户 API 常见目标=p95 300-500ms、p99 < 1s；移动端因网络波动需按产品调整。
事实（OneUptime 的强制手段）：用 OpenTelemetry 的 histogram（P50/P95/P99）定义性能预算并自动告警——预算不是文档是告警阈值。
事实（设计方法）：端到端体验预算（如 500ms p95）先定，再逆向分配到网络→网关→后端——内部调用预算收紧（100ms）防止尾延迟吃光总预算。
推测：solo 的延迟事故源几乎都是「新端点上线时没预算概念」——加一个慢查询（无索引的 LIKE）就把 p95 顶穿。预算的价值=在 PR 阶段就有「这个端点允许多少 ms」的对话。

目标先写死：对外 API p95<500ms、p99<1s；内部 p95<100ms——写进 API 文档每端点一行（与 opc-cache-ttl-strategy 的端点分级并排）。
只看 p95/p99 不看平均：监控面板把 average 隐藏（眼睛只看分位数）——opc-monitoring-basics-solo 的面板加 p95 行。
预算=告警阈值：p95 超预算连续 10 分钟即告警——「预算」没有告警就是愿望。
优化顺序：先索引和缓存（p95 大头），最后才考虑代码微优化——尾延迟通常来自 N+1 查询和冷缓存。