第 3 章 性能工程：从纳秒到毫秒

本章把前两章的硬件事实变成可计算的工具：延迟数量级、排队与扩展定律、观测方法与基准测试纪律。

学习目标

读完本章，你应当能够：

1. 只用一张延迟表做心算换算：把"一次跨机房调用"折成内存访问次数、CPU 周期数与 L1 命中次数。
2. 推导 Little 定律 L = λ × W，并由 QPS 与延迟估算并发数、由并发数与延迟估算吞吐上限、由三者估算线程池规模。
3. 写出 Amdahl 定律与 Gustafson 定律，区分强扩展与弱扩展，用算例证明"串行占比 5% 时加速比上限为 20"。
4. 按对象正确选用 USE 方法与 RED 方法，并说出两者的指标口径为什么不能互换。
5. 计算扇出 N 时"至少一个下游变慢"的概率 1 − (1 − p)^N，并解释平均值为什么掩盖尾延迟。
6. 识别基准测试的五个陷阱，说出每个陷阱伪造出的是哪一类错误结论。
7. 复述"先测量再优化"的闭环，说明为什么优化后必须做回归与代价核算。

前置知识检查

3.1 延迟数字表：把量级变成心算能力

第 1 章给出了各级存储的量级，本节把它压缩成一张必须背到能心算的表。背这张表的用途不是复述数字，而是在面试现场快速判断一个方案是否根本不可能达标：如果需求是"单请求 P99 小于 20 ms"，那么任何在同步路径上做两次跨机房调用的设计都已被排除，不需要再看代码。

表 3-1 可心算的延迟数字表

心算的第一条规则：折成"内存访问次数"。 除法在表内完成，乘法只在最后做一次。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

换算练习（全部心算，除完再乘）

  ① 一次跨机房调用（0.5 ms）= 500 μs，而 1 次内存访问 = 0.1 μs
     ⟹ 0.5 ms ≈ 5 × 10³ 次内存访问（5000 次）
  ② 一次 SSD 随机读（100 μs）≈ 1000 次内存访问
     ⟹ "每次请求查一次盘"等价于"每次请求多访问 1000 次内存"
  ③ 一次跨大洲 RTT（150 ms）≈ 1.5 × 10⁶ 次内存访问（150 万次）
  ④ 反过来问：2000 次内存访问是多少？
     每次 0.1 μs ⟹ 2000 × 0.1 μs = 200 μs ⟹ 约等于一次 SSD 随机读
  ⑤ 一次跨机房调用 vs 一次 L1 命中：0.5 ms / 1 ns = 5 × 10⁵ 倍

★ 记住这条"除数轴"：ns → μs → ms 每步 1000 倍，跨越两步就是 10⁶ 倍。
  硬件世界里 10⁶ 倍的差距不可能靠调优参数抹平，只能靠换层次（缓存、本地化、异步）。

第二条规则：折成 CPU 周期。 在 1 GHz 下 1 个周期 = 1 ns，于是"ns 数就等于周期数"。3 GHz 下除以 3，量级不变。这条折算能立刻暴露两类错误设计：一是把 μs 级操作放进热循环（1000 周期一次的操作放在每请求循环里）；二是把 ms 级操作放进同步路径（150 万周期的一次跨洲往返，同步等它等于让 CPU 空转 150 万周期）。真正的收益来自把等待变成并行：等待可以重叠，计算不能。

3.2 吞吐与延迟：Little 定律的推导与用法

**吞吐（throughput）**是单位时间内完成的请求数（QPS/TPS），延迟（latency）是单个请求从进入到完成的时间。两者量纲不同、瓶颈不同、优化手段不同，却被平均值混为一谈，这是性能讨论里最常见的第一误区。

• 为什么可以不同步：处理是流水线式的。给一条 10 级流水线喂入 10 倍请求，单请求延迟几乎不变（仍是 10 级），吞吐却涨到 10 倍。延迟由最慢的一环加上排队时间决定，吞吐由瓶颈资源的容量除以单位工作量决定。
• 什么时候会同步恶化：当资源利用率接近饱和，排队时间按 1/(1 − ρ) 发散，延迟急剧上升（这就是 3.5 节尾延迟的排队论来源），而吞吐因为被瓶颈钉住而不再增长。所以"吞吐到顶 + 延迟起飞"是同一次资源饱和的两个侧面。

两者的数量关系就是 Little 定律（Little’s law）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

Little 定律：L = λ × W

  定义：L = 系统内的平均请求数（并发度，包含"正在被处理"与"还在排队"）
        λ = 请求到达率（每秒到达数，稳态下等于完成率 = 吞吐）
        W = 单个请求在系统内的平均停留时间（排队时间 + 服务时间）

  推导一（计数法，最直观）：
    设观测窗口 T 内共完成 N 个请求，每个请求在系统内停留 Wᵢ，则
      平均并发  L = (1/T) × Σ Wᵢ
      平均到达率 λ = N / T
    ⟹ λ × W = (N/T) × (1/N) × Σ Wᵢ = (1/T) × Σ Wᵢ = L   恒等成立
    ★ 关键点：这个恒等式对"到达过程"和"服务时间分布"没有任何假设，
      不要求泊松到达，不要求指数服务时间，只要求在观测窗口内系统守恒
      （进入数 = 离开数 + 仍在系统内的数）。

  推导二（面积法，等价但更几何）：
    把每个请求画成一条从进入到离开的横条（横轴时间、纵轴请求序号），
      Σ Wᵢ = 所有横条的面积 = 系统内请求数随时间的积分 ≈ L × T
    而 N ≈ λ × T，两边同除 T 即得 L = λ × W

用法一：由 QPS 与延迟反推并发数（最常考）。 设 QPS = 1000、平均延迟 W = 20 ms = 0.02 s，则 L = 1000 × 0.02 = 20，即系统里平均有 20 个请求在途。

用法二：由并发数反推吞吐上限。 设线程池固定 8 个工作线程、每个请求服务时间 50 ms，则 λ_max = L / W = 8 / 0.05 = 160 QPS。此时再调大上游超时或加大重试都没有意义——吞吐上限由并发度与单请求时间锁死，只能降 W（优化单请求耗时）或升 L（加并发，前提是不撞到下一个瓶颈，见第 31 章 31.2 节的线程数公式）。

用法三：判定"加线程是否有用"。 用一个可测的量来判断：利用率 ρ = λ × S（S 为纯服务时间，不含排队）。ρ < 1 是稳态条件；若实测 ρ 已接近 1 且队列在增长，此时加线程只会增加上下文切换与缓存抖动（见第 5 章 5.5 节的切换开销构成），吞吐不升、延迟更差。

表 3-2 三个量的相互换算（含排队时间的口径陷阱）

3.3 Amdahl 定律与 Gustafson 定律：强扩展与弱扩展

Amdahl 定律（Amdahl’s law）回答：工作量固定时，增加处理器能获得多少加速比？Gustafson 定律（Gustafson’s law）回答：执行时间固定（问题规模随处理器一起放大）时，能获得多少加速比？前者是强扩展（strong scaling），后者是弱扩展（weak scaling）。两者的差异不在数学，而在被固定的量不同。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

Amdahl 定律（固定问题规模）
  设：并行部分占比例 p（按串行执行时间计），串行部分占 s = 1 − p，处理器数 n
  串行执行时间 T₁ = 1（归一化）
  并行执行时间 Tₙ = s + p/n
             1
  加速比 S(n) = ───────────
              s + p/n

  渐近上限：S(∞) = 1/s      ← 令 n → ∞，p/n → 0

  串行占比 s = 5% ⟹ S(∞) = 1/0.05 = 20
    n = 8 ：S = 1 / (0.05 + 0.95/8)  = 5.9259  ≈ 5.93  ← 8 核只拿到 5.93×
    n = 64：S = 1 / (0.05 + 0.95/64) = 14.95
    n = ∞ ：S = 20                          ← 无论多少核，永远越不过 20
  ★ 8 核的并行效率 = 5.93 / 8 = 74.1%；核数越多效率越低。n = 1.90 / 3.48 分别对应 2 核与 4 核：
    核数少时"看起来还行"，上限的伤害要到中高核数才显形。

Gustafson 定律（固定执行时间，规模随 n 放大）
  设：串行部分占比例 s（按"放大后的总工作量"计），处理器数 n
  放大后的工作量 = s + n × (1 − s)      ← n 个处理器各自处理同样大小的一份
  加速比 S(n) = s + n × (1 − s) = n − s × (n − 1)

  s = 5%：
    n = 8：S = 0.05 + 8 × 0.95 = 7.65       ← 接近 8，效率 95.6%
    n = 64：S = 0.05 + 64 × 0.95 = 60.85
  ★ 对比同参数下的 Amdahl：8 核 5.93 对 7.65，64 核 14.95 对 60.85。
    随着 n 增大，Amdahl 趋于常数 20 而 Gustafson 线性增长 —— 这就是两条定律
    对"多核有没有前途"给出相反结论的原因：它们问的根本不是同一个问题。

为什么 5% 的串行部分把上限压到 20？ 关键在于 S(∞) = 1/s 这个极限是用"串行比例"定义的，不是用"串行耗时"定义的。串行部分本身没有变慢，它只是在总时间里的占比被无限放大的并行加速顶到了 100%：n → ∞ 时 p/n → 0，总时间 Tₙ → s，于是只剩串行部分在跑。这也解释了敏感性：s = 1% 时上限 100，s = 10% 时上限 10，s = 20% 时上限 5——串行占比每翻一倍，上限就砍一半。

必须能枚举"串行部分"长什么样，否则这条定律只是公式：单线程完成的初始化与配置加载、全局锁保护的临界区（见第 6 章 6.2 节）、内存分配器与内核路径中的全局数据结构、日志落盘与序列化、启动/终止阶段、以及分布式场景下的协调成本（选主、屏障、全局有序 ID、跨分片聚合）。还有一类容易被忽略的"伪并行"：任务切分过细时，调度与合并本身成为串行开销。

3.4 USE 方法与 RED 方法：观测对象决定指标口径

性能排查最大的浪费不是工具不够，而是不知道该看哪些指标，于是把 CPU 使用率从头看到尾。两个方法解决"看什么"的问题，但它们的适用对象根本不同：USE 面向资源，RED 面向服务。

表 3-3 USE 方法与 RED 方法的适用对象差异

表 3-4 四类核心资源的 USE 指标映射

RED 的指标口径：Rate 是每秒请求数（要区分成功与失败的口径），Errors 是失败请求数与失败率（要区分"客户端错误"与"服务端错误"，两者的告警含义不同），Duration 是响应时间分布——不是平均值，而是 P50/P90/P99/P999 分位数（原因见 3.5 节）。

3.5 P99/P999 与尾延迟：平均值如何掩盖问题

为什么平均值会掩盖问题，用一个具体分布算一遍就清楚了。设 100 个请求中有 99 个耗时 10 ms、1 个耗时 1 s：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

九个数字看清"平均值骗局"（单位 ms）

  算术平均 = (99 × 10 + 1 × 1000) / 100 = 1990 / 100 = 19.9 ms
  中位数 P50 = 10 ms
  P90 = 10 ms       ← 90% 的请求都比它快
  P99 = 1000 ms     ← 恰在分界点上，取第 99 个排序值
  P999（需要样本量 ≥ 1000 才有意义）在 100 个样本里无法估计

  ★ 平均值 19.9 ms 看起来"还好"，但最慢的 1% 用户经历了 100 倍于中位数的延迟。
  ★ 分位数才是用户体验的坐标：
      P50 决定"大部分人的体感"，P99/P999 决定"有多少人抱怨、有多少请求超时重试"。
  ★ 另一个陷阱：平均值本身会被少数极值拉动（19.9 是中位数 10 的两倍），
    因此它既不代表典型用户，也不代表最差用户 —— 它不代表任何人。

**尾延迟（tail latency）**指分布最右侧的分位数（通常 P99 及以上）。它之所以必须单独关注，有三个互相独立的理由：

1. 它决定超时与重试的地板线。若超时阈值设成平均值，则必然有一大批请求超时；超时触发重试又把流量放大，反过来推高延迟（见第 35 章 35.3 节熔断与退避）。
2. 它是用户体验的实际下限。用户的一次页面加载往往由多个请求组成，只要有一个慢，整体就慢——这就是下面的扇出放大。
3. 它是 SLO 的直接标的。可用性目标本质上是"在 X ms 内完成的比例达到 Y%"。

尾延迟放大（tail amplification）的数学。 设一个请求需要同时（并发）调用 N 个下游，每个下游"变慢"（超过阈值）的独立概率为 p。整体不变慢要求 N 个下游全都不慢，概率 (1 − p)^N，于是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

至少一个下游变慢的概率 = 1 − (1 − p)^N

  推导：N 个下游各自独立，"全部正常"的概率 = (1−p) × (1−p) × … × (1−p) = (1−p)^N
        由补事件得"至少一个异常"的概率，这是德摩根律的直接应用

  算例 A：p = 1%（单个下游的 P99 就是慢阈值）
    N = 10 时 1 − 0.99¹⁰ = 9.56%  ← 单依赖的"P99"被放大成整体的"P90 附近"
    N = 100 时 1 − 0.99¹⁰⁰ = 63.40%；N = 200 时 1 − 0.99²⁰⁰ = 86.60%
  算例 B：p = 1‰（更严，单依赖的 P999 才是慢阈值）
    N = 10 时 1 − 0.999¹⁰ ≈ 1.00%；N = 100 时 1 − 0.999¹⁰⁰ ≈ 9.52%
    ← 要求整体 P90 达标，单依赖就必须做到 P999 以上

  ★ 关键推论：若希望整体在 p_target 以内，单个下游的慢概率必须低于
      p ≤ 1 − (1 − p_target)^(1/N) ≈ p_target / N     （p_target 很小时）
    即"扇出 N 倍，对每个依赖的尾延迟要求就严格约 N 倍"。

表 3-5 扇出倍数 N 与"至少一次慢"的概率（p 为单个依赖的慢概率）

四条工程对策（每条都对应公式里的一项）：压 N——减少同步扇出，把可选的依赖改成异步或预取/批量；压 p——对最慢的下游做专项优化，并把慢请求快速失败而不是无限等待；去独立性假设——1 − (1 − p)^N 假设各下游独立，而真实系统里的慢往往由共享资源（同一个机架、同一个连接池、同一次 GC 停顿）引发，此时概率是正相关的，实际尾延迟会比公式预测的更差，这是面试官最爱追问的一层；兜底——用对冲请求（hedged request，向第二个副本再发一份、取先返回者）与超时预算（timeout budget，把整条链路的剩余预算逐跳向下传）把尾延迟的上界钳住。

3.6 基准测试的五个陷阱

基准测试（benchmark）的目标是得到一个能支持决策的结论（这个改动快了 30%），而五个陷阱各自伪造出一类错误结论。表 3-6 是必背清单。

表 3-6 基准测试的五个陷阱与伪造出的错误结论

两个补充的隐藏陷阱值得主动提：一是缺少对照组——一次只改一个变量，并保留改动前的基线（同一次运行窗口内 A/B 交叉执行，避免"上午测基线、下午测优化"被环境漂移污染）；二是把微基准当结论——单函数微基准（microbenchmark）受死代码消除、常量折叠、循环展开影响极大，JMH 这类框架用黑洞（blackhole）与多轮 fork 对抗，但微基准收益绝不能外推为端到端收益（某函数优化 50%、它只占总耗时 2%，端到端上限即 1%，见 3.3 节 Amdahl）。

3.7 性能优化的正确流程：先测量，再优化，最后回归

不要猜——这句话在面试里的分量比任何优化技巧都重。原因很直白：一个陌生系统的瓶颈分布无法靠直觉判断，而优化错了地方，收益为零且引入风险。流程如下。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

性能优化闭环（每一步都有产物，缺一环结论就不可信）

  ① 定义指标与目标            产物：SLI/SLO（口径、分位数、窗口、流量口径）
        │                     反例："让服务更快" —— 不可验证
        ▼
  ② 建立可重复的基线           产物：固定配置的基线报告（含预热、样本量、分布）
        │                     ★ 没有基线，后面的"提升"都是故事
        ▼
  ③ 定位瓶颈在哪一层           产物：证据（火焰图/采样/队列长度），不是猜测
        │                     手段：RED 找端点 → USE 找资源 → 剖析找代码行
        ▼
  ④ 提出假设并预测收益         产物：一句话假设 + 预期幅度
        │                     例："序列化占 30% 耗时，换零拷贝应降 20%"
        ▼
  ⑤ 单变量修改并复测           产物：A/B 交叉执行的对照结果
        │                     ★ 一次只改一个变量，否则无法归因
        ▼
  ⑥ 回归验证 + 代价核算        产物：全局无退化的证据 + 代价清单
        │                     查：吞吐、P99、错误率、资源占用、成本
        └──────────▶ 回到 ①（新基线），继续下一轮

  关键判据：③ 的输出必须是"机制 + 证据"，而不是"我猜是 GC"。

表 3-7 一次请求的分层归因：证据落在哪一层，修法就完全不同

顺序原则：先判断时间是花在 CPU 上还是等待上。CPU 高就看应用剖析；CPU 不高却慢就必然在等某样东西，用 off-CPU 火焰图或链路追踪找出等待对象，再回到上表定位层。

优化手段只该有四类（想不出归类说明还没定位到瓶颈）：减少工作量（消除冗余计算与重复 RPC、降数据量）、摊销（批量化、合并小 I/O、连接复用）、并行/异步（把等待重叠，见 3.1 节）、换层次（把数据搬到更快的层次）。

回归验证的三个必查项：一是全局指标不能退化——针对 P99 的优化经常抬高 P50（例如为压低长尾而增加批处理，普通请求多等一个批次窗口），或者压低延迟而抬高 CPU（缓存换 CPU）；二是极端场景不能崩——缓存失效、下游全挂、冷启动、数据量放大 10 倍；三是代价与成本核算——多用的内存、连接数、机器成本是否值得这点延迟收益（性能优化从来是取舍）。

本章小结

自测题

Q1（计算）需求：接口 P99 必须小于 10 ms。某方案在请求同步路径上包含一次同机房 RPC（0.3 ms）和一次 SSD 随机读（100 μs），另有 2 ms 的本地计算。仅按量级判断这个方案是否可行，并给出至少两条可行的改造方向。

Q2（计算）服务实测 2000 QPS、平均响应时间 25 ms，线程池上限 64。请用 Little 定律判断线程池是否够用；若平均响应时间升到 40 ms 而 QPS 不变，结论如何变化？

Q3（推导）某服务串行部分占 8%。分别用 Amdahl 定律与 Gustafson 定律求 16 核时的加速比，并解释为什么两个答案差异这么大，以及在面试中应该用哪一个来论证"扩容是否有效"。

Q4（辨析）“我们给这个 HTTP 接口做了 USE 分析：利用率 30%、饱和度低、错误率 0，所以接口没问题。“这句话错在哪？修正后应该怎么观测？

Q5（计算）一个聚合接口需要并发调用 20 个下游服务。每个下游单次调用"超过 200 ms"的概率是 0.5%，且各下游相互独立。求该接口"至少一次超 200 ms"的概率。若要把这个概率压到 1% 以内，每个下游的慢概率需要降到多少？

面试高频问题与陷阱

延伸阅读

• John L. Hennessy & David A. Patterson, Computer Architecture: A Quantitative Approach（第 6 版第 1 章）：Amdahl 定律与"性能的度量与报告"一节，是 3.3 节的规范表述来源；同书关于强扩展与弱扩展的讨论。
• Gene M. Amdahl, “Validity of the single processor approach to achieving large scale computing capabilities”（1967，AFIPS）；John L. Gustafson, “Reevaluating Amdahl’s Law”（1988，CACM）——两条定律的原始论文，对照读能看清"被固定的量不同"这一核心差异。
• Raj Jain, The Art of Computer Systems Performance Analysis：Little 定律的严格推导（守恒律视角）、排队论基础与基准测试设计章节（预热、重复次数、置信区间）。
• Brendan Gregg, Systems Performance: Enterprise and the Cloud（第 2 版）：第 2 章"方法"（USE 方法的完整定义）、第 3 章"操作系统"、第 12 章"基准测试"（五个陷阱的工程化清单与反例）。
• Tom Wilkie 关于 RED 方法的公开文章（Weaveworks 工程博客），以及 Google SRE Book 第 4 章"Service Level Objectives"（SLI/SLO 口径、分位数与错误预算的官方表述）。
• Dean & Barroso, “The Tail at Scale”（Communications of the ACM, 2013）：尾延迟放大的完整论述、相关性来源，以及对冲请求（hedged request）、微分区（micro-partition）、选择性复制等对策的原始出处。
• Linux man-pages：mpstat(1)、vmstat(8)、iostat(1)、ss(8)、perf-stat(1)——3.4 与 3.6 节各指标的口径定义。