实验设计与方法论 on Dorkytiger 的小屋

单变量与对照组

Mon, 01 Jan 0001 00:00:00 +0000

5.1 单变量与对照组

上一节：无　|　下一节：5.2 预热、稳态与运行时长配套代码：05-experiment-design/01-single-variable

一句话结论

一次实验只改一个变量，其余全部冻结。 没有对照组，就没有结论——你只有「改完之后的一组数字」，无法判断它是不是真的因为你的改动而变化。

一、用「试药」理解单变量

假设一个病人吃了三种药，病好了。哪种药起了作用？

可能只有第一种有效；
可能只有第三种有效；
可能前两种无效，第三种和第一种组合才有效；
甚至可能是自愈（和药无关）。

这就是「同时改三处」的问题：你得到了一个结果，但无法归因。

医学上解决这个问题的办法是随机对照试验（RCT）：

试验组：只吃新药
对照组：只吃安慰剂
其余条件（年龄、病程、饮食）尽量一致

性能实验完全一样：

医学	性能实验
试验组	改动后的版本
对照组（安慰剂）	改动前的版本（基线）
随机分组	同样的负载、数据、环境
控制变量	一次只改一个

关键：性能实验里的「安慰剂效应」同样存在——你自己的期望会影响你怎么配置环境、怎么解读数据。这就是为什么需要对照组和客观的判定标准。

二、什么叫「其余全部冻结」

一个合格的实验，除了那一个变量，下面这些都必须完全一致：

类别	具体项
代码	commit hash、依赖版本、构建产物
JVM	JDK 版本、完整启动参数（堆、GC、其他 `-XX`）
机器	实例规格、CPU 型号、是否容器、容器 limit
数据	规模、分布、缓存状态、预热程度
负载	压测脚本（必须版本化）、到达率、并发模型、时长
观测	指标采集方式、火焰图采样参数、测量点
外部条件	时间（避开备份/定时任务）、机房/可用区、下游状态

这张表就是第 1 章 1.7 节「实验元数据」的完整版。任何一项变了，实验就不是单变量的。

三、四种常见的「伪单变量」实验

❶ 同时改代码和 JVM 参数

❌ 实验：把 -Xmx 从 2g 改成 4g，同时加了一个索引
   结果：P99 降了 40%
   结论：？？？（无法归因）

修法：分成两次实验。先改索引（代码层，通常收益更大），测完；再单独调堆。

预热、稳态与运行时长

Mon, 01 Jan 0001 00:00:00 +0000

5.2 预热、稳态与运行时长

上一节：5.1 单变量与对照组　|　下一节：5.3 重复、抖动与异常值配套代码：05-experiment-design/02-warmup-and-duration

一句话结论

压测时长不是拍出来的，是由「周期」决定的。 你必须至少覆盖一个完整的最长周期——GC 老年代回收周期、缓存 TTL、定时任务间隔、连接池回收周期。30 秒的压测结论只能当烟雾测试。

一、用「煮饭」理解预热与时长

煮一锅饭：

阶段	状态	对应
前 2 分钟	水还没开，米是硬的	冷启动：JIT 未编译、连接池空、缓存冷
中间 10 分钟	沸腾、米在吸水	过渡态：数据不能代表最终结果
最后 5 分钟	稳定收汁	稳态：可以判断饭好不好

三个关键推论：

「尝一口」不能判断饭好了没——你需要知道现在处于哪个阶段。
时间不够，饭就是生的——再好的米也没用。
不同米需要的时间不同——长粒米和短粒米不一样，就像不同应用需要的预热时间不同。

所以：预热时长要看「是否进入稳态」，运行时长要看「是否覆盖了所有周期性事件」。

二、预热：怎么判断「够了」

❌ 错误做法：固定预热 N 轮或 N 秒

「JMH 默认预热 5 轮，那就够了。」
「压测前先跑 60 秒预热。」

为什么错：不同应用需要的预热量差几十倍。一个启动加载 500 个类的应用，和一个 20 个类的工具，不可能同时进入稳态。

✅ 正确做法：看方差收敛（滚动 CV）

已在第 2 章 2.4 节详述。核心判据：

CV（变异系数）	判断
> 10%	明显没稳，继续预热
5% – 10%	接近稳态，再等等
< 5%	可以开始测量
< 2%	环境很干净，数据可信度高

同时要覆盖的四件事（JVM 之外还有）：

重复、抖动与异常值

Mon, 01 Jan 0001 00:00:00 +0000

5.3 重复、抖动与异常值

上一节：5.2 预热、稳态与运行时长　|　下一节：5.4 环境隔离清单配套代码：05-experiment-design/03-repetition-and-outliers

一句话结论

一次运行的结果不是结论，是一个样本。 你至少需要 3–5 轮重复才能看到分布。而异常值不能"觉得不好看就删"——必须能解释成因，否则它可能正是你需要面对的真实情况。

一、用「投篮命中率」理解重复

判断一个球员的命中率，你不会只看他投一次：

做法	问题
只投 1 次（进了）	可能是运气
只投 1 次（没进）	也可能是运气
投 100 次	开始有意义
投 100 次，但把没进的都算作"手滑了"	自欺

性能实验完全一样：

❌ 「跑了一次，P99 = 95ms，达标」
✅ 「跑了 5 次，P99 = 93, 96, 94, 210, 95 ms，中位数 95ms」
                                  ↑ 这一轮需要解释

二、该跑几轮

轮数	能做什么	局限
1 轮	只能发现「明显的崩溃」	无法区分差异与噪声
3 轮	能看到波动范围，取中位数	推荐的最低要求
5 轮	能做简单的统计检验（非参数检验需要足够样本）	时间成本
10 轮以上	能估算置信区间	只在关键决策时值得

权衡：3–5 轮是性价比最高的区间。如果环境噪声大（CV > 10%），增加轮数的收益不如先改善环境。

环境隔离清单

Mon, 01 Jan 0001 00:00:00 +0000

5.4 环境隔离清单

上一节：5.3 重复、抖动与异常值　|　下一节：5.5 数据集设计配套代码：05-experiment-design/04-environment-isolation

一句话结论

实验环境里任何「你没关掉的东西」，都会变成数据里的噪声。 而与性能测试不同，噪声不会报错——它只会让你的结论变得不可信，而你往往察觉不到。

一、用「化学实验的洁净室」理解环境隔离

化学实验里，一点灰尘就可能让结果完全偏差。所以：

化学实验室	性能实验
无尘环境	独占的测试机器
恒温恒湿	固定的 CPU 频率、无降频
纯净试剂	真实但固定的数据集
空白对照	基线组
记录环境参数	采集环境元数据

关键差异：化学实验的污染通常是可见的（溶液变色），性能实验的污染是不可见的——你只会看到一个稍微高一点的 P99，然后开始怀疑代码。

二、五类污染源与处理方式

❶ 同一台机器上的其他负载

污染源	影响	处理
压测客户端与服务同机	互相抢 CPU，两个方向都失真	必须分离（最低要求：不同容器 + CPU 限制）
IDE / 浏览器 / 本地开发	抢占 CPU 与内存	关掉
其他服务实例	争抢资源	独占环境
监控 agent	持续采集消耗资源	记录其开销，或降频采样

❷ 机器自身的周期性任务

污染源	频率	表现	处理
数据库 autovacuum	不定	磁盘 IO 尖刺	实验前手动 `VACUUM ANALYZE`，期间可临时调整 `autovacuum` 参数
数据库 checkpoint	不定	IO 抖动	观察 checkpoint 配置与日志时间戳
日志轮转	按大小/时间	磁盘写尖刺	避开轮转时刻，或临时调大阈值
备份任务	通常夜间	全盘 IO 与网络	实验前确认已关闭
`cron` / 定时任务	各种	周期性 CPU/IO	`pgrep -a -f cron` 确认
系统更新	不定	突发 CPU/IO	关闭自动更新

❸ CPU 频率与调度

污染源	影响	处理
CPU governor（节能模式）	频率波动 → 延迟抖动	设为 `performance`
Turbo Boost	前后跑的基准频率不同	要么固定频率，要么全程接受 turbo（关键是一致）
未绑核	线程在不同核间迁移，缓存失效	`taskset` 绑定
超线程干扰	同一物理核上的两个逻辑核互相影响	明确是否启用，并保持一致
NUMA 跨节点	内存访问变慢	`numactl` 绑定

❹ 云环境的不可控因素

污染源	表现	处理
邻居抢占（steal）	`st` 指标高，延迟抖动	换独占型实例；或多次实验取可比时段
网络路径变化	跨 AZ 调用延迟变化	固定可用区；记录网络拓扑
存储 IOPS 配额	IO 突发受限	确认卷类型与 IOPS 上限
宿主机维护	突发迁移	记录实验期间的事件

❺ 实验自身的干扰

污染源	影响	处理
高开销剖析（profiler）	占用 CPU，抬高 P99	基线组和实验组必须用同样的观测配置
详细日志（DEBUG）	同步 IO，可能占 10%+	统一日志级别
`/metrics` 高频抓取	序列化开销	统一 scrape interval
压测机自身瓶颈	实际到达率低于设定值	每次压测先验证到达率（第 4 章 4.1）

三、实验前的检查清单（脚本化）

## 环境检查（实验前逐项确认）

### 机器
- [ ] CPU governor = performance
- [ ] 已绑核（或明确不绑核，并保持一致）
- [ ] 关闭了自动更新
- [ ] 无其他无关进程（`ps aux --sort=-%cpu | head`）
- [ ] `st`（steal）< 1%（多次采样确认）

### 容器
- [ ] CPU limit 与生产一致
- [ ] 内存 limit 与生产一致
- [ ] 无 sidecar 干扰（或已计入）
- [ ] 节流比例 < 1%（`/sys/fs/cgroup/cpu.stat`）

### 数据库
- [ ] autovacuum 状态已知（关闭或已记录）
- [ ] 无长事务（`pg_stat_activity`）
- [ ] 统计信息已更新（`ANALYZE`）
- [ ] 连接数无人抢占

### 服务
- [ ] JVM 参数与生产一致
- [ ] 日志级别一致
- [ ] 观测配置一致（JFR/profiler）
- [ ] 服务已重启（避免上一轮热状态污染）

### 压测
- [ ] 客户端独立机器/容器
- [ ] 脚本已冻结快照
- [ ] 已预热（或明确预热阶段）
- [ ] 到达率可验证

### 记录
- [ ] 环境元数据已采集（第 1 章 1.7）
- [ ] 环境事件时间线已开启记录

四、绑核与频率固定的具体命令

# ① 固定 CPU 频率（Linux）
sudo cpupower frequency-set -g performance
# 验证
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# ② 绑定到指定核（服务用 2-5，压测客户端用 6-7，互不干扰）
taskset -c 2-5 java -jar app.jar
taskset -c 6-7 k6 run loadtest.js

# ③ NUMA 绑定
numactl --cpunodebind=0 --membind=0 java -jar app.jar

# ④ 查看 NUMA 拓扑
numactl --hardware

# ⑤ 容器内限制 JVM 看到的核数（避免线程池过大）
java -XX:ActiveProcessorCount=2 -jar app.jar

# ⑥ 关闭 swap（避免内存压力导致的抖动）
sudo swapoff -a

注意：绑核能降低噪声，但也可能降低吞吐（因为无法利用其他核）。如果实验目的是测「最大吞吐」，绑核会让结果偏低。关键是「一致性」而不是「绝对最优」——基线组和实验组用同样的配置即可。

数据集设计

Mon, 01 Jan 0001 00:00:00 +0000

5.5 数据集设计

上一节：5.4 环境隔离清单　|　下一节：5.6 统计基础配套代码：05-experiment-design/05-dataset-design

一句话结论

数据集的「规模」决定执行计划，数据集的「分布」决定缓存命中率与锁竞争。 这两件事都会让结论完全翻转——用均匀分布压测出的「达标」，在真实的幂律流量下可能完全不达标。

一、用「试衣模特」理解数据集

服装品牌用标准身材的模特试衣服，然后量产。问题在于：

模特	真实顾客
身高 175、三围标准	身高 150–195，各种体型
只是一个人	分布很重要

如果只用模特试，你只能确认「这件衣服在标准身材上好看」——不能确认它适合大多数人。

数据集完全一样：

数据集维度	如果做错了	后果
规模	用 1 万行测，线上 1 亿行	执行计划不同（索引 vs 全表扫描）
分布	用均匀分布测，线上是幂律	缓存命中率虚高、锁竞争虚低
冷热	只测热缓存	上线后冷启动的 P99 是热态的几十倍

二、规模：为什么「同数量级」不够，要「同级」

执行计划会随数据量改变

数据量	PostgreSQL 可能选择
1 千行	全表扫描（反正很快）
10 万行	索引扫描
1 亿行	索引扫描 + 更复杂的计划（并行查询、位图扫描）

关键：执行计划的转折点不是线性的。 你可能在 10 万行时看到「走索引、P99 = 5 ms」，在 1 亿行时完全一样；但也可能在 100 万行时突然因为统计信息或选择性变化而改走全表扫描。

统计基础（够用版）

Mon, 01 Jan 0001 00:00:00 +0000

5.6 统计基础（够用版）

上一节：5.5 数据集设计　|　下一节：5.7 噪声底线与回归检测配套代码：05-experiment-design/06-statistics-basics

一句话结论

只需要三个工具就够用：变异系数（CV，衡量数据稳不稳）、置信区间（衡量估计有多准）、非参数检验（判断两组差异是否真实）。不要用 t 检验——延迟分布不是正态的。

一、用「法庭举证」理解统计

法庭上要证明「被告有罪」，不能只说「看起来像他」。要给出证据强度：

法庭	统计
「证据确凿」	p < 0.01
「证据充分」	p < 0.05
「证据不足」	p > 0.05
「无法排除合理怀疑」	差异在噪声范围内

性能实验也要求「证据强度」。只说「优化后快了」是不够的——要说明这个差异有多大概率不是偶然。

二、工具一：变异系数（CV）——衡量数据稳不稳

CV = 标准差 / 均值

用途：判断测量环境的质量。

CV	判断	行动
< 3%	环境很干净	可以做细微差异的判断
3% – 5%	可接受	常规结论可信
5% – 10%	偏大	只能判断较大差异（> 10%）
> 10%	环境有问题	先修环境，任何结论都不可信

关键理解：CV 是「你的尺子的精度」

如果你的 CV 是 8%，那么：
  5% 的「优化」→ 无法确认（在噪声范围内）
  30% 的「优化」→ 可以确认

这就是第 7 节「噪声底线」的核心：CV 决定了你能声称的最小差异。

噪声底线与回归检测

Mon, 01 Jan 0001 00:00:00 +0000

5.7 噪声底线与回归检测

上一节：5.6 统计基础　|　下一节：5.8 实验记录与常见反模式配套代码：05-experiment-design/07-noise-floor-and-regression 本节是本章的核心。 它回答一个问题：在你的环境里，多大的差异才算「真实差异」？

一句话结论

噪声底线 = 在代码完全不变的情况下，你重复实验能得到多大的差异。 它是你判断一切性能结论的标尺：低于噪声底线的"优化"，无论听起来多合理，都无法被你的数据证实。

一、用「体重秤的精度」理解噪声底线

你家的体重秤有 ±0.5 kg 的误差。今天称是 70.0 kg，明天是 69.7 kg。

你能说「我减了 0.3 kg 吗？

不能——因为 0.3 kg 小于秤的精度。

正确说法：「在秤的精度范围内，体重没有变化。」

性能实验完全一样：

如果你的环境噪声底线是 ±8%：
  P99 从 210ms 到 198ms（-5.7%） → ❌ 无法确认
  P99 从 210ms 到 150ms（-28.6%）→ ✅ 可以确认

关键：噪声底线不是「你可能做到多精确」，而是「你的工具实际有多精确」。它由环境（云主机、后台任务、GC 抖动）决定，不由你的意愿决定。

二、怎么测噪声底线（六步）

① 冻结一切：代码、数据、负载、环境、观测配置全部不变
② 重启服务（确保从同一初始状态开始）
③ 完整跑一次实验（含预热），记录 P50/P95/P99、QPS、错误率
④ 重复 5–10 次（每次都重启 + 预热）
⑤ 计算每个指标的均值、标准差、CV
⑥ 定义噪声底线 = 该指标的最大波动范围

关键要求

要求	为什么
代码一字不改	否则测的不是噪声
每次都重启服务	否则上一轮的热状态会影响下一轮
至少 5 次	3 次看不出分布形态，5 次能看出基本范围
记录每一轮的值	不只看 CV，还要看是否有趋势（是否在变好/变坏）

输出示例

═══ 噪声底线测量（10 轮，代码未改动）═══

轮次  QPS     P50    P95    P99    错误率
   1  498.2   32.1   68.4   93.2   0.00%
   2  499.1   33.0   70.2   96.1   0.00%
   3  497.5   32.4   67.9   94.0   0.00%
   4  498.8   34.2   74.1  103.5   0.00%   ← 偏高
   5  499.4   32.8   69.3   95.2   0.00%
   6  498.0   32.5   68.8   94.4   0.00%
   7  499.7   33.1   70.5   96.8   0.00%
   8  498.3   32.9   69.1   95.0   0.00%
   9  499.2   32.6   68.2   93.8   0.00%
  10  498.6   33.3   71.0   97.2   0.00%

指标   中位数   最小值   最大值   波动范围   CV
QPS    498.8   497.5   499.7    ±0.22%    0.13%
P50     32.8    32.1    34.2    ±3.2%     1.8%
P95     69.2    67.9    74.1    ±4.5%     2.7%
P99     95.1    93.2   103.5    ±5.4%     3.1%

═══ 结论 ═══
噪声底线（取最大波动范围的 1.5 倍作为安全边际）：
  QPS : ±0.3%
  P50 : ±5%
  P95 : ±7%
  P99 : ±8%

含义：低于以下差异的结论，在本环境中不可信：
  优化声称 P99 改善 < 8%  → 无法确认
  优化声称 P50 改善 < 5%  → 无法确认

三、噪声底线的三个用处

用途一：判断「优化是否可信」

优化前 P99 中位数 = 210 ms
优化后 P99 中位数 = 195 ms
差异 = -7.1%

噪声底线 = ±8%

结论：❌ 差异在噪声范围内，无法确认优化有效

注意：这不是说「优化无效」，而是说「你的数据不足以证明它有效」。可能需要：

实验记录与常见反模式

Mon, 01 Jan 0001 00:00:00 +0000

5.8 实验记录与常见反模式

上一节：5.7 噪声底线与回归检测　|　下一节：5.9 Lab 5 配套代码：05-experiment-design/08-records-and-antipatterns

一句话结论

实验记录的目的不是"存档"，而是"让三个月后的你或另一个人能复现出同样的结论"。 而反模式是九种常见的自欺方式——它们的共同点是「让结论看起来比实际更有力」。

一、一份合格的实验记录包含什么

已在第 1 章和 docs/experiments/_TEMPLATE/ 里给出了完整模板。这里强调本章新增的四项：

新增项	为什么
轮数与每轮结果	单次结果不是结论（第 3 节）
CV 与噪声底线	判断差异是否可信的标尺（第 7 节）
统计检验结果	差异显著性的证据（第 6 节）
环境事件时间线	解释异常轮的依据（第 3 节）

一个完整的「结果」章节应该长这样

## 结果

### 环境（12 轮实验期间）
- 噪声底线（本环境，P99）：±8%（CV 3.1%，见 E05-noise 实验）
- 环境事件：T+15min 有一次日志轮转（已记录，未造成异常）

### 逐轮结果
| 轮次 | QPS | P50 | P95 | P99 | 错误率 | 备注 |
| --- | --- | --- | --- | --- | --- | --- |
| 1 | 498 | 32.1 | 68.4 | 93.2 | 0.00% | |
| 2 | 499 | 33.0 | 70.2 | 96.1 | 0.00% | |
| 3 | 497 | 32.4 | 67.9 | 94.0 | 0.00% | |
| 4 | 498 | 34.2 | 74.1 | 103.5 | 0.00% | ⚠️ 日志轮转期间 |
| 5 | 499 | 32.8 | 69.3 | 95.2 | 0.00% | |

### 汇总
- P99 中位数：95.2 ms（全部 5 轮）/ 94.6 ms（剔除第 4 轮）
- 四分位距：93.8 – 96.1 ms
- CV（轮间）：3.1%

### 统计检验
- 与基线（E03 的 210 ms）对比：Mann-Whitney U，p = 0.008 → 显著
- 差异幅度：-55%（远大于噪声底线 8% 和 MDD 16%）

### 结论
优化有效。P99 从 210 ms 降到 95 ms，改善 55%，统计显著且远超噪声底线。

二、九种反模式

❶ Cherry-picking（挑好看的一次）

❌ 「我们测了 5 次，最好的那次 P99 是 88 ms，达标了。」

为什么错：这是选择性地报告数据，等于把噪声当成能力。

Lab 5：量化你自己的噪声底线

Mon, 01 Jan 0001 00:00:00 +0000

5.9 Lab 5：量化你自己的噪声底线

上一节：5.8 实验记录与常见反模式　|　下一节：第 6 章分析与定位配套代码：05-experiment-design/09-lab5 预计时长：90 分钟

一、这个 Lab 的目标

产出你自己环境的噪声底线，并用它验证统计方法。

做完之后你会得到一个数字——低于这个数字的"优化"，你以后就不该声称。这个数字是你后续所有实验的标尺。

二、任务清单

#	任务	产出	时长
1	冻结环境（按第 4 节清单）	环境检查记录	20 min
2	跑 10 轮相同配置实验	10 组原始数据	40 min
3	计算噪声底线与 MDD	噪声底线表	15 min
4	显著性验证（5% 与 30% 两个改动）	两次判定结论	15 min

三、任务 1：冻结环境

按第 4 节的清单逐项确认，并记录：

## 环境检查记录

- CPU governor: __________
- 绑核配置: __________
- 容器 CPU limit: __________
- 容器内存 limit: __________
- 节流比例（实验前）: __________
- 压测客户端位置: 独立机器 / 独立容器 / 同机（⚠️）
- 后台任务检查:
  - [ ] 已关闭备份
  - [ ] 已关闭日志轮转（或临时调大阈值）
  - [ ] 数据库 autovacuum 状态已知
- JVM 参数: __________
- 观测配置（JFR/profiler）: __________
- `st`（steal）采样值: __________

关键要求：实验期间（10 轮）不做任何改动——包括不调参数、不部署、不打开 IDE。