第2章：延时度量指标——延迟、吞吐量、P95/P99与尾延迟
做SDK优化，第一件事不是改代码。是搞清楚你要优化什么。
我见过不少团队，上来就盯着平均延迟猛调。调了半天，用户反馈还是慢。为什么？因为平均延迟会骗人。你想想看，把100个10ms的请求和1个10s的请求平均一下，结果才不到20ms。看起来不错，但那个10s的请求已经把用户气跑了。
所以这一章，咱们把几个核心指标掰开揉碎讲清楚。
2.1 延迟与吞吐量——两个最基本的概念
延迟，说白了就是“发请求到收响应，花了多久”。单位一般是毫秒。我个人习惯把延迟想象成“水管里的水流速”——水管再粗，水流太慢也没用。
吞吐量，是“单位时间能处理多少请求”。单位一般是QPS（每秒查询数）或TPS（每秒事务数）。它更像“水管有多粗”。
举个例子：一个API，平时100QPS时延迟5ms。压到1000QPS，延迟飙到50ms。这时候你光优化延迟没用，得从架构层面解决吞吐瓶颈。
我在项目中遇到过这么个事：客户说“延迟很高”，我们查了半天发现是连接池太小，请求在排队。调整一下就正常了。所以，看指标不能只看一个。
2.2 P95与P99——别再被平均值骗了
平均值就像“全班平均分”，考得好的和考得差的一平均，你根本看不到真实情况。
P95 是指：把采集到的所有延迟从小到大排序，排在第95%位置的那个值。换句话说，95%的请求都比它快。P99同理，是第99%位置的值。
为什么要看P95/P99？
- 它们能暴露长尾问题。平均延迟10ms，P99可能是500ms。这500ms的体验足以让用户卸载你的App。
- 它们是真实用户体验的反映。大多数用户都处在P95或P99区间。
实际使用中，我建议：
- 日常监控看P95，能反映大多数用户感受。
- 核心链路看P99，不能容忍意外慢请求。
- P999一般留给超敏感场景，比如高频交易。
2.3 尾延迟——最可怕的那个“尾巴”
尾延迟，就是指分布中最靠后的那部分延迟。通常用P99、P99.9来衡量。你能想象吗？系统99%请求都在10ms内完成，剩下1%可能要5秒。这1%的尾延迟，足以破坏整个系统的稳定性。
为什么尾延迟这么可怕？
- 它会引发连锁反应。一个慢请求阻塞了线程池，后面的请求跟着等，雪球越滚越大。
- 用户容忍度极低。一个请求卡了3秒，用户可能已经切换到竞品了。
我有个习惯：做压力测试时，永远盯着P99和P99.9。只要这两个值出现抖升，立马停止压测，先排查根因。不是所有人都能接受“差不多就行”，对吧？
2.4 一个表格看清各指标
下面这个表格，帮你快速对比四个核心指标。我建议你把这个表格贴在工位上，每次评估SDK性能时对照着看。
| 指标 | 定义 | 适用场景 | 优化重点 |
|---|---|---|---|
| 延迟 | 单次请求耗时 | 实时交互场景 | 减少中间环节、优化网络 |
| 吞吐量 | 单位时间处理请求数 | 批量处理、高并发 | 扩容、并发优化 |
| P95 | 95%请求的延迟上限 | 日常监控、用户感知 | 消除中低频异常 |
| 尾延迟 | P99/P99.9的异常值 | 核心链路、敏感业务 | 超时、熔断、降级 |
嗯，你看，每个指标的关注点完全不同。只看一个，等于盲人摸象。
2.5 一张图理清度量体系
磨刀不误砍柴工。我把这四个指标的关系画成了一幅流程图。你一看就明白它们的依赖和用途。
你看这个图，从底层的原始数据出发，一步步提炼出延迟、吞吐量、P95/P99和尾延迟。每个指标都有它的位置。优化时你得先确定：我的业务最不能忍什么？如果是用户交互卡顿，盯紧尾延迟；如果是支撑高并发，盯吞吐量。
最后说一句真话：没有任何一个指标能独立衡量SDK的好坏。你要像拼图一样，多指标组合着看，才能看清全貌。