这一章在做什么

什么时候翻这一章

• 要比较两个版本、两套编译选项谁更快先确认差别大过波动：多跑几次、看分布，必要时比指令数。§12.3.9§12.3.6场景手册 →
• 压测时吞吐上不去，不知道卡在哪跑的时候开着观测工具，先问「为什么不是两倍」：常常卡在压测客户端自己。§12.3.2§12.3.10场景手册 →
• 要定一台服务能扛多少并发一档一档加负载，同时记延迟分布，报延迟还能接受的那一点，不报最高点。§12.3.7
• CI 里的性能回归测试，数字每次都在抖先量清楚噪声有多大，再定多大的变化算回归；排查定时任务、邻居、缓存冷热。§12.1.3§12.3.9场景手册 →
• 厂商、博客或同事甩来一个跑分先做乘法核对上限，再拿问题清单问配置、时长、错误率和瓶颈。§12.3.8§12.4

这一章不讲新工具，用的都是前面各章的：CPU 看第 6 章，磁盘看第 9 章，网络看第 10 章。扩展性模型（Amdahl、USL）的出处在 §2.6，均值、标准差、变异系数在 §2.8。

先用中文过一遍

随手测和主动测：数字要带着「卡在哪」一起交

写过 C++ 微基准的人多半遇到过：改了一行，基准快了 30%，再跑一次又回去了；或者一个循环跑出 0.0 纳秒。这些都是基准测试最常见的失败：工具量到了某个东西，只是不是你想量的那个。书里把它概括成一句话，本页在「值得停下来的句子」里引了原文：测的是 A，实际量到 B，结论却说成 C。

§12.1.3 列了十六种失败。本站把它们连同后面几节讲到的坑归成三类，方便对照自己：量错了对象（测盘测成了页缓存、测服务测成了压测客户端、编译器把被测代码删了）；环境不对（测试机没按生产调优、两次测试之间不止一个因素变了、邻居和定时任务在捣乱）；读错了结果（只跑一次、只看平均值、没看错误率）。还有几种是厂商和市场部的事：为跑分专门改产品（benchmark specials）、只公布对自己有利的配置。

对策只有一个：主动基准测试（active benchmarking）。基准跑着的时候，用这本书前面讲的工具去看系统：哪个资源满了，CPU 时间花在谁身上，盘到底动没动。作者检查清单的第一问是「为什么不是两倍」：吞吐停在 12 万，是什么挡住了它到 24 万？答出来，你就知道了瓶颈；如果瓶颈不是你想测的那个部件，这个结果就不该拿去下结论（§12.3.10）。顺带的好处是，这时系统上跑的是一个你知道的负载，正好用来检验自己会不会读这些工具。

微基准、模拟、回放：各能说明什么

按负载像不像真实情况，基准分三种。微基准（micro-benchmark）只测一种操作：一种系统调用、一种 IO、一个函数。好处是简单，结果差了能很快找到原因；代价是它和你的真实负载之间隔着一层映射，要自己判断哪一两个维度和你有关（§12.2.1）。模拟（simulation，也叫宏基准）按生产负载的特征造请求，比如按测出来的比例混合读写；它能带出组件之间的相互影响，但容易只模拟平均值、漏掉突发（§12.2.2）。回放（replay）把抓到的真实请求重放一遍，听起来最真，可一旦新系统的延迟变了，录下来的客户端不会像真实客户那样跟着反应，回放的层次选错了还会测错对象（§12.2.3）。

设计微基准时，书里说每一项测试都还要再乘上两个维度。一是工作集大小（working set size）：数据远小于内存，测的是缓存和软件路径；远大于内存，才开始测到盘。二是线程数：单线程看单核速度，多线程看整机上限。只测理想条件的叫「晴天测试」，还要补上有竞争、有干扰、负载起伏的「雨天测试」（§12.2.1）。自己写微基准，书里推荐 C，因为它和实际执行的东西对得上；但要提防编译器把结果没用到的计算整个删掉，跑的时候用别的工具确认它真的在干活，必要时看反汇编（§12.3.6）。下面的第一个动手实验就是这个坑。

负载渐增：吞吐和延迟一起看

想知道系统最多扛多少，最直接的办法是一档一档加负载（ramping load）：每加一个线程或一批客户端，记下吞吐，直到不再上涨，画出来就是扩展性曲线（§12.3.7）。曲线可以直接看形状，也可以拿模型去套：Amdahl 定律描述有一段工作只能串行时，曲线逐渐变平；USL（通用扩展性定律）再加一项线程之间互相同步的开销，曲线过了峰值会往下掉（§2.6.3、§2.6.4）。下面的模拟器就是这三条线。

只看吞吐不够。接近上限时请求开始排队，延迟会先慢慢涨、再陡地涨上去。硬加负载，吞吐也许还能多挤出几个百分点，但那时每个请求都在排长队，这个最高点对用户没有意义。书里的建议是记延迟分布，问一句这个延迟客户能不能接受，报的是延迟还在可接受范围内的那一点。

先算上限，再看波动：两道算术

合理性检查（sanity check）就是做乘法：结果需要哪个部件跑多快，有没有超过它的物理上限（§12.3.8）。换成读者的场景：一块 ARM 板只有百兆网口，100 Mbit/s 除以 8 是 12.5 MB/s，扣掉协议头实际到不了这么多；如果有人说在这块板上测出 NFS 读 30 MB/s，不用看任何细节就知道，读的是客户端缓存，请求根本没走网络。书里说，一旦发现结果超了某个上限，多数时候最后都会查出这个结果是假的。

第二道算术是波动。同一个基准连跑十次，结果不会一样：别的进程、中断、CPU 频率、缓存冷热都在扰动它。只跑一次，你不知道它落在分布的哪里；两个版本各跑一次，差 3% 可能只是噪声。书里给的办法是跑得够久（至少不短于一秒）、多跑几次看标准差，比较两组结果时要知道误差范围（§12.1.3、§12.3.9）。变异系数（标准差除以均值）把波动变成一个数，两个版本差的百分比还没有它大，就很难说谁快（定义见 §2.8.4，后半句是本站的经验说法）。

方法：按什么顺序查

§12.3 开头有一张方法表，九种方法里只有被动基准测试是反面例子，其余都围着同一件事：别只收数字，要分析。下面是本站按「做一次基准测试」的先后排的七步，前三步决定这个测试值不值得跑，后四步决定结果能不能信。

1. 这个测试和我的问题有关吗？

   先写下要回答的问题，再看真实负载长什么样：读多还是写多、IO 多大、工作集比内存大还是小、并发多少。测一个生产里根本不走的路径，数字再漂亮也没用。§12.3.5§12.1.3

2. 基准程序本身读得懂吗？

   优先用短小、开源、读得完的工具，或者自己写一个只做这一件事的。自己写的 C/C++ 微基准，要用掉计算结果，免得被编译器删掉。§12.3.6

3. 跑的时候，瓶颈在哪？

   开着 pidstat -u -t 1、mpstat -P ALL 1、iostat -xz 1：被测对象有没有哪个资源到了 100%；压测客户端有没有一个核先满；盘到底动没动。都没满，说明你还没把系统推到头。再用 perf record 看时间花在谁的代码里。§12.3.2§12.3.3§12.3.4

4. 负载加到多少就该停？

   一档一档加并发，每档记吞吐和延迟分布（p50、p99）。吞吐变平、延迟陡增的地方就是上限，报延迟仍可接受的那一档。§12.3.7

5. 这个数在物理上可能吗？有没有出错？

   把吞吐换算成字节每秒，和网口、盘、内存带宽比；看压测工具报的错误数和超时数。错误请求通常返回得很快，会把平均延迟拉低、吞吐抬高。§12.3.8§12.1.3

6. 再跑一次还是这个数吗？

   至少跑五到十次，报均值和标准差（或中位数和分布）。比较两个版本，差别要明显大过波动；用 perf stat -r 10 顺手拿到误差范围和指令数。§12.3.9

7. 交结果时附上了什么？

   数字之外，写清楚配置、跑了多久、跑了几次、瓶颈是什么，以及哪些假设还没来得及核实（比如「假设这个测试真的走到了盘」）。没有分析的裸数字，书里认为多半是一次调查的开始，而不是结论。§12.1.3§12.3.10

拿到别人的跑分、又摸不到那台机器时，本站从 §12.4 的问题里挑出最常用的几组：它测的负载和我的像不像；被测的是一台机器还是一个集群，多少钱；跑了多久、跑了几次，报的是平均值还是峰值，波动多大；成功和失败各占多少；瓶颈是什么，有没有用别的工具确认过；存储类的再问工作集多大、缓存在哪一层命中；网络类的再问拓扑和调过哪些协议栈参数。

工具速查

pidstat、mpstat、iostat、sar 在 sysstat 包里，perf 在 linux-perf 包里，objdump 在 binutils 里；strace、iperf3、fio、wrk 在 Debian 上都是同名的包，sysbench（书里提到的 CPU 微基准）也是。本节的命令都不需要 root，perf 不加 -a 时只能看自己这个用户的进程。要反复比较两条命令的耗时，Debian 13 还有 hyperfine 包，它会自动多跑几次并报均值和标准差。工具名的链接到本站的工具卡：pidstat、mpstat、iostat、strace、perf、sar、iperf3、fio、wrk。

动手：在自己的机器上试

// sum.c：测「把一个数组加起来」每个元素要多久
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

#define N (1 << 24)          // 16M 个 int，64 MB，比 CPU 缓存大得多
#define ROUNDS 20

static double now(void) {
    struct timespec t;
    clock_gettime(CLOCK_MONOTONIC, &t);
    return t.tv_sec + t.tv_nsec / 1e9;
}

int main(void) {
    int *a = malloc(N * sizeof *a);
    for (int i = 0; i < N; i++) a[i] = i & 7;

    double t0 = now();
    long long s = 0;
    for (int r = 0; r < ROUNDS; r++)
        for (int i = 0; i < N; i++) s += a[i];
    double t = now() - t0;

#ifdef KEEP
    printf("sum=%lld  ", s);   // 用掉结果，编译器就不能把循环删掉
#endif
    printf("%.4f ns/元素\n", t * 1e9 / ((double)N * ROUNDS));
    free(a);
    return 0;
}

$ gcc -O2 sum.c -o sum_bad
$ gcc -O2 -DKEEP sum.c -o sum_ok
$ ./sum_bad; ./sum_ok
# 各跑 10 次，看指令数和误差范围
$ perf stat -r 10 -e task-clock,instructions:u ./sum_bad
$ perf stat -r 10 -e task-clock,instructions:u ./sum_ok
# 自己算 10 次的均值、标准差和变异系数
$ for i in $(seq 10); do ./sum_ok; done | awk '{x=$2; s+=x; q+=x*x; n++} END {m=s/n; sd=sqrt((q-n*m*m)/(n-1)); printf "平均 %.4f 标准差 %.4f CV %.1f%%\n", m, sd, 100*sd/m}'

sum_bad:  0.0000 ns/元素
sum_ok:   sum=1174405120  0.1284 ns/元素

sum_bad:  29,498,766  instructions:u
          0.0469 +- 0.0005 seconds  ( +- 1.06% )
sum_ok:  952,246,496  instructions:u
          0.0962 +- 0.0013 seconds  ( +- 1.34% )

第一轮 10 次：平均 0.1374 标准差 0.0170 CV 12.4%
第二轮 10 次：平均 0.1404 标准差 0.0093 CV 6.6%

// ramp.c：N 个线程，每次先在本地算一会儿，再拿锁更新一张共享的表
// 用法：./ramp 线程数 [秒数]；默认跑 1 秒，打印每秒完成的操作数
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define WORK 150             // 锁外的本地计算量
static pthread_mutex_t mu = PTHREAD_MUTEX_INITIALIZER;
static unsigned long table[64];   // 共享数据：锁里要改它
static volatile int stop;
static unsigned long done_ops[64];

static void *worker(void *arg) {
    long id = (long)arg;
    unsigned x = id + 1, n = 0;
    while (!stop) {
        for (int i = 0; i < WORK; i++) x = x * 1103515245 + 12345;   // 锁外：可以并行
        pthread_mutex_lock(&mu);                                     // 锁里：只能串行
        table[x % 64] += x;
        pthread_mutex_unlock(&mu);
        n++;
    }
    done_ops[id] = n;
    return NULL;
}

int main(int argc, char **argv) {
    int nt = argc > 1 ? atoi(argv[1]) : 1;
    pthread_t th[64];
    for (long i = 0; i < nt; i++) pthread_create(&th[i], NULL, worker, (void *)i);
    int secs = argc > 2 ? atoi(argv[2]) : 1;
    sleep(secs);
    stop = 1;
    unsigned long total = 0;
    for (int i = 0; i < nt; i++) { pthread_join(th[i], NULL); total += done_ops[i]; }
    printf("%2d 线程  %8.0f 次/秒\n", nt, (double)total / secs);
    return 0;
}

$ gcc -O2 -pthread ramp.c -o ramp
# 负载渐增：1、2、4、8、16 个线程各跑 1 秒
$ for n in 1 2 4 8 16; do ./ramp $n; done
# 主动基准测试：跑着的时候看它的 CPU 花在用户态还是内核
$ ./ramp 1 3 & sleep 0.5; pidstat -u -p $! 1 2
$ ./ramp 16 3 & sleep 0.5; pidstat -u -p $! 1 2
$ ./ramp 16 3 & sleep 0.5; pidstat -wt -p $! 1 1
# 用户态的时间花在哪
$ perf record -g ./ramp 16
$ perf report --stdio --no-children

 1 线程    7664767 次/秒
 2 线程   13651311 次/秒
 4 线程   10771869 次/秒
 8 线程   10667901 次/秒
16 线程   10336982 次/秒

pidstat     %usr   %system      %CPU
 1 线程   100.00      0.00    100.00
16 线程   241.50   1236.50   1478.00

pidstat -wt（16 线程，每个线程）  cswch/s 约 13000

perf report:  59.59%  worker
              23.27%  pthread_mutex_lock

动手：模拟器

先猜：竞争系数 α 是 0.05、一致性系数 β 是 0.001 时，加到多少个线程吞吐最高？最高是单线程的几倍？把 β 拖到 0，曲线还会往下掉吗？再看模拟器验证。

1. 点「一把大锁」：β = 0，USL 和 Amdahl 重合。把横轴改到 128，曲线越来越平，但永远不往下掉；天花板是 1000 ÷ 0.1 = 10000。再把 β 拖到 0.0005，看峰值出现在哪。
2. 点「锁加数据同步」，然后连点「渐增负载」：1、2、4、8、16、32、64。前两档接近翻倍，之后越涨越少；过了 N*（约 22）再加，吞吐不涨反跌。只测 1 和 64 两档，会得出什么结论？
3. 点「本站 ramp.c 的拟合」：五个实测点和 USL 曲线对得并不好，1 到 2 线程的跳跃模型解释不了。按 §2.6.2 的说法，模型和数据对不上的地方值得去查：要么模型不对，要么系统里发生了模型没考虑的事（这里是锁从用户态快路径换成了进内核睡眠）。

成书之后

分节地图

这一章分四块：背景和常见失败（§12.1），基准的种类（§12.2），方法（§12.3），问题清单（§12.4）。上手只需要讲「怎样算有效」的 §12.1.2 和方法里的几节：主动基准测试、自己写基准、负载渐增、合理性检查、问题清单。十六种失败那一节很长，当清单查。

1. There are lies, damn lies…约 300 词开篇微基准和宏基准的区别；基准的数字该怎么理解、怎么对应到自己的环境。
2. Background约 100 词背景一句引子。
3. Reasons约 500 词为什么做基准测试选型、调优、回归测试、容量规划等用途；云上做基准变便宜了。
4. Effective Benchmarking约 700 词有效的基准测试好基准的几个特征；用基准时必须弄清的四件事；分析要在跑的时候做。
5. Benchmarking Failures约 2800 词基准测试的失败十六种常见失败，从随手测到作弊。怀疑某个结果时回来对照。
6. Benchmarking Types约 100 词基准的种类按负载像不像真实情况排成一条谱。
7. Micro-Benchmarking约 500 词微基准测试优缺点；设计时要乘上工作集大小和线程数两个维度。
8. Simulation约 400 词模拟按生产负载特征造请求；无状态和有状态的模拟。
9. Replay约 200 词回放重放真实请求为什么也会测错。
10. Industry Standards约 600 词行业标准基准TPC、SPEC 的来历和清单。选购整机、读厂商资料时才用得上。
11. Methodology约 100 词方法九种方法的总表，分成实验、观察、统计几类。
12. Passive Benchmarking约 200 词被动基准测试跑完不管的做法，以及它的结果可能错在哪几处。
13. Active Benchmarking约 700 词主动基准测试跑的时候用工具一层层确认测的是什么。这一章最该精读的一节。
14. CPU Profiling约 300 词CPU 剖析对基准和被测对象都做剖析，常能很快发现意外。
15. USE Method约 100 词USE 方法要么有部件到了 100%，要么你还没把系统推到头。
16. Workload Characterization约 100 词负载特征拿生产负载的特征和基准对比，判断相关性。
17. Custom Benchmarks约 200 词自己写基准为什么用 C；编译器会删代码；写基准时的意外收获。
18. Ramping Load约 600 词负载渐增一档档加负载画扩展性曲线；为什么要同时看延迟。
19. Sanity Check约 300 词合理性检查用乘法核对结果有没有超过物理上限。
20. Statistical Analysis约 500 词统计分析机器紧张时多收数据、事后分析；要记录波动和误差范围。
21. Benchmarking Checklist约 200 词基准测试检查清单拿到结果先问的六个问题；第一问常常就能解决问题。
22. Benchmark Questions约 400 词问基准的问题拿到厂商结果时可以问的长清单，按 CPU、存储、网络分组。
23. Exercises约 100 词习题习题；本页的两个动手实验覆盖了它的实践部分。

词与短语

只收先读和用到再查两档的节。斜体那一行是原句里连续的几个词，在电子书里搜它就能找到那一句。

§0 开篇

§12.1.1 Reasons

§12.1.2 Effective Benchmarking

§12.1.3 Benchmarking Failures

§12.2.1 Micro-Benchmarking

§12.2.2 Simulation

§12.2.3 Replay

§12.3.1 Passive Benchmarking

§12.3.2 Active Benchmarking

§12.3.3 CPU Profiling

§12.3.6 Custom Benchmarks

§12.3.7 Ramping Load

§12.3.8 Sanity Check

§12.3.9 Statistical Analysis

§12.3.10 Benchmarking Checklist

§12.4 Benchmark Questions

诊断题：换成你来查

场景和输出都是本站编的。先自己判断，再点选项看解释。

Device     w/s     wkB/s   %util
mmcblk0    0.0       0.0     0.0
mmcblk0    0.0       0.0     0.0
（基准结束几秒后）
mmcblk0  712.0   91136.0    99.2

服务端   %usr  %system   %CPU  Command
         96.0    84.0   180.0  server
压测端   %usr  %system   %CPU  Command
         61.0    38.0    99.0  wrk

旧版本   102 ms   97 ms   108 ms   平均 102.3
新版本    99 ms   94 ms   101 ms   平均  98.0

并发    QPS       p99
  32    96000    12 ms
  64    99000    35 ms
 128   101000   140 ms

  Non-2xx or 3xx responses: 1912330
Requests/sec:  90112.45
Transfer/sec:     14.20MB

值得停下来的句子

Casual benchmarking: you benchmark A, but actually measure B, and conclude you’ve measured C.— §12.1.3。本站译：随手测：你测的是 A，实际量到的是 B，结论却说你量了 C。

三个字母对应三个环节：设计、执行、解读，每一环都可能出岔子，而且互不相干。工具可能完全正常，却量到了别的东西（测盘量成了页缓存）；量对了，结论还可能说过头（微基准快了 10%，就说服务快了 10%）。读完这一章再看自己写过的基准，可以挨个问：我打算测什么，跑的时候工具说它在干什么，我最后写下的结论有没有超出它。

If you’ve spent less than a week studying a benchmark result, it’s probably wrong.— §12.1.3。本站译：如果你研究一个基准结果的时间不到一周，它多半是错的。

这话听着夸张，书里紧接着给了退路：没时间细查的话，就把没来得及核实的假设写在结果旁边，比如「假设这个测试真的走到了盘」「假设压测工具没有先到上限」。对日常开发也适用：PR 里贴的性能数字，附上跑了几次、波动多大、瓶颈在哪，就比一个裸数字可信得多。

带走的几条

一句话：跑基准的时候就去看系统，说清它卡在哪，结果才算数。