6.2 性能调优方法论：压测定位验证
文档摘要
6.2 性能调优方法论：压测、定位、验证 本节摘要：调优的最大误区是"背参数"——把别人的 MaxRequestWorkers 抄过来当偏方。正确的循环是：压测建立基线 → 观察瓶颈信号 → 定位到流水线的一段 → 一次只改一处 → 复测对比。本节给出压测阶梯的设计方法、连接/CPU/后端/IO 四大瓶颈段的特征判据，以及把前五章所有调优手段串成决策树的完整方法论。 这一节要建立的能力 阅读完本节，你应当能够： 设计阶梯加压的压测方案并建立可复现的基线； 用系统与 httpd 指标识别四大瓶颈段； 按"一次一改"的纪律执行调优并留存证据； 把前五章的调优手段按瓶颈对号入座。 先立规矩：调优三律 第一条：没有基线就没有调优。改动前后的对比数据是唯一可信的证据，"感觉快了"不算。
6.2 性能调优方法论：压测、定位、验证
本节摘要：调优的最大误区是"背参数"——把别人的 MaxRequestWorkers 抄过来当偏方。正确的循环是：压测建立基线 → 观察瓶颈信号 → 定位到流水线的一段 → 一次只改一处 → 复测对比。本节给出压测阶梯的设计方法、连接/CPU/后端/IO 四大瓶颈段的特征判据，以及把前五章所有调优手段串成决策树的完整方法论。
这一节要建立的能力
阅读完本节，你应当能够：
- 设计阶梯加压的压测方案并建立可复现的基线；
- 用系统与 httpd 指标识别四大瓶颈段；
- 按"一次一改"的纪律执行调优并留存证据；
- 把前五章的调优手段按瓶颈对号入座。
先立规矩：调优三律
第一条：没有基线就没有调优。改动前后的对比数据是唯一可信的证据，"感觉快了"不算。基线要固定变量：同样的压测参数、同样的数据集、同样的时段（避开日志轮转等干扰）。
第二条：一次只改一处。同时改三个参数，性能提升了 20%，你不知道是哪个参数的功劳，更不知道哪个参数其实在帮倒忙。
第三条：压测要像真实流量。压静态首页得出的参数，撑不住动态+图片混合的真实负载；请求大小、keep-alive 比例、读写比都要贴近生产画像。没有真实画像前，用访问日志回放是最诚实的压测。
压测阶梯：怎么加压、看什么
设计一个阶梯方案：并发从 10 起步，每档翻倍（10、20、40、80、160、320），每档持续 60–120 秒，记录四类数据：吞吐（请求每秒）、延迟分位（重点看 95 与 99 分位）、错误率、资源水位（CPU、内存、连接数、后端队列）。
# 用 ab 做单档压测（正式评估建议用更完整的工具） ab -c 160 -t 120 -k https://www.example.com/mixed-page | grep -E "per second|95%|Failed"
阶梯压测的典型曲线会经历三个阶段：线性区（并发翻倍吞吐翻倍，延迟平稳）、拐点区（吞吐增长放缓，延迟开始爬升）、饱和区（吞吐不升反降，延迟陡增、错误出现）。拐点就是你的真实容量，调优的目标要么是把拐点右移（扩容量），要么是降低单位请求的成本（省资源）——两条路在第 2 章参数、第 5 章缓存里分别给了工具。
四大瓶颈段的特征与判据
瓶颈无非四段，各有指纹：
| 瓶颈段 | 典型指纹 | 确认手段 | 调优工具 |
|---|---|---|---|
| 连接层 | scoreboard W 满、监听队列堆积、CPU 不高 | mod_status + ss | MPM 参数（第2章）、KeepAlive、event 化 |
| CPU 层 | 用户态 CPU 打满、上下文切换高 | top + 压缩过滤开销 | 压缩白名单（5.2）、减模块、升硬件 |
| 后端层 | 504/后端慢、FPM 或数据库饱和 | 后端自身指标 | FPM 池容量（4.3）、缓存（5.1）、代理超时（4.2） |
| IO 层 | iowait 高、磁盘队列长、静态文件慢 | 系统监控 | 缓存、sendfile 类优化、SSD |
判据要交叉验证：scoreboard 的 W 满可能是工作线程不够，也可能是后端慢把线程全拖住——前者 CPU 忙，后者 CPU 闲。CPU 闲而延迟高，问题几乎总在等待上（后端、IO、锁）；CPU 忙而吞吐低，问题在计算上（压缩、解析、低效规则）。这两句话能砍掉一半的误诊。
图 6-2 性能瓶颈定位决策树
把工具箱挂到决策树上
回望全书，调优手段已经全部发过，这里按瓶颈归位：
连接层瓶颈：第 2 章的 MPM 参数与模型迁移（prefork→event 是单项收益最大的一步）、KeepAliveTimeout 调节、监听队列；第 5 章 HTTP/2 让单连接承载更多请求，连接压力结构性下降。
CPU 瓶颈：第 5 章压缩白名单与预压缩；第 1 章"不用的模块不加载"在这里兑现成真实 CPU 节省；第 3 章重写规则精简（每条正则都是每请求的 CPU 开销，规则越靠后匹配越贵，把高频规则前移）。
后端瓶颈：第 5 章缓存是首选（免生成的请求不占后端）；第 4 章 FPM 池容量与均衡器分流；ProxyTimeout 让后端故障不拖垮前端。
IO 瓶颈：静态文件大亨利好缓存（浏览器长缓存让请求根本不来）；服务器侧 mod_cache 磁盘缓存把热内容钉在本地；极端场景上内存缓存后端。
一个真实的调优案例走一遍方法论。症状：新闻站晚高峰 95 分位延迟 3 秒。基线压测发现拐点在并发 80，scoreboard 一片 W、CPU 仅 40%。三个问题：CPU 不忙 → 等待瓶颈；错误少量 504 → 后端慢；iowait 低 → 不是磁盘。定位：后端层。候选手段：FPM 池扩容 or mod_cache。按"一次一改"先开 60 秒 mod_cache（改动小、可回滚），复测拐点移到并发 200、95 分位降到 800 毫秒——固化，收工。若没达标，下一轮再动 FPM。整个过程两天，每一步都有数据档案。
调优的边界：何时该停止
性能工作有边际效应：95 分位从 3 秒到 800 毫秒是质变，从 800 到 700 毫秒多数用户无感。在没有业务痛点的指标上继续抠，是工程 Vanity。我的停止条件：延迟分位满足业务承诺、错误率近零、高峰期资源水位有 30% 余量——三者齐备，把精力投去稳定性与安全，比继续压榨最后 10% 更有价值。
本节要点回顾
- 三律：无基线不调优、一次一改、压测贴近真实画像；
- 拐点即容量：线性区、拐点区、饱和区三段曲线，调的是拐点位置；
- 诊断双句：CPU 闲延迟高查等待，CPU 忙吞吐低查计算；
- 四段瓶颈：连接、CPU、后端、IO，各有指纹与确认手段；
- 工具归位：全书调优手段按瓶颈段挂到决策树上取用；
- 停止条件：分位达标、错误近零、水位有余量，别做 VANITY 优化。
💡 一句话记住本节：调优不是找最优参数，是找到瓶颈、消掉它、然后用数据证明你做到了。
下一节给流水线装行车记录仪：日志与排错。