Nginx 与 PHP-FPM 调优：没有实测数据时，怎样建立可核对的基线
文章说明在缺少可核验正文与实测记录的情况下，Nginx 与 PHP-FPM 调优应先确定比较口径、布置观测点、一次只改一个变量并保留回滚路径；给出的配置仅为未执行的占位示例，具体默认值与版本行为待核实。
本次没有可用的正文素材，因此这篇文章不提供“调优后的性能数字”，也不推荐照抄任何参数。能确定的只有方法边界：Nginx 与 PHP-FPM 的调优必须先有可比的基线和可回滚的变更记录，否则无法判断改动是否有效。下文给出流程骨架和未执行的配置示例；具体指令的默认值、可用版本与行为差异，需按你实际部署的版本查文档核实（待核实）。
先把“变快”拆成可观测的量#
“性能调优”是一个结果词，不是指标。落地时至少要分开四类量：
- 延迟分布：只看平均值会被长尾掩盖，需同时看分位数；
- 错误与超时：5xx、上游超时、连接被重置要单独计数；
- 资源饱和度：CPU、内存、磁盘 I/O、文件描述符；
- 排队与等待：请求在 Nginx 与上游之间停留的时间。
这四类量必须在同一时间窗、同一负载模型、同一基期下比较。缺少基期的“优化前后对比”不构成结论，只能算一次观察。
观测点：把一次请求的耗时拆成段#
Nginx 侧可以用日志变量记录总请求时间与上游响应时间，两者之差大致对应 Nginx 自身处理、网络与客户端侧的开销。这只是一个可用于定位的差值，不等于因果结论。PHP-FPM 侧可启用慢请求日志与状态页；状态页会暴露进程与队列信息，应限制访问来源，不要直接对公网开放。
这些机制属于通用能力，但指令名、默认值与统计口径在不同版本间可能有差异，本文未在具体版本上核对（待核实）。
变更顺序：一次只动一个变量#
- 记录基线：固定负载与时间窗，保存原始日志，而不是只保存截图。
- 写下假设：例如“等待发生在 FPM 进程排队，而不是上游计算”。
- 只改一项配置，并在变更记录里写明改前值、改后值与回滚方式。
- 用同一负载复测，比较同一分位与同一错误口径。
- 未达预期就回滚，不要在一个版本上叠加多项改动。
常见误判是把 CPU 占用高直接当成瓶颈；也可能是进程数增加后内存不足引发换页，反而拉长延迟。另一类问题是超时值互不匹配：Nginx 等待上游的时间短于上游自身超时，就会出现“上游还在算、连接已被放弃”的假故障。
示例配置（未执行，占位值）#
以下片段仅演示观测字段与配置项的位置，未在任何环境执行，参数需按实际环境填写并复测。
# 未执行的示例：Nginx 侧记录时间字段
log_format timing '$request_time $upstream_response_time $status';
access_log /var/log/nginx/timing.log timing;; 未执行的示例：PHP-FPM 池配置占位
pm = dynamic
pm.max_children = YOUR_VALUE
request_slowlog_timeout = YOUR_VALUE
slowlog = /var/log/php-fpm/slow.log占位符 YOUR_VALUE 不是推荐值。进程池容量取决于单请求常驻内存与可用内存，这两个量必须在本机测量，不能从他人文章里迁移。
结论与边界#
在缺少可核验数据时，能负责任地给出的只有流程：先定口径，再布观测点，再单变量变更，最后保留回滚。至于具体的并发数、缓冲区大小与超时取值，属于环境相关量，本文不提供，也不应被当成默认答案。上线前请以你所部署版本的官方文档为准核对指令语义，并保留你自己的测量记录。
