PHP OPcache JIT 对数值循环性能的评估方法

我第一次给一段 PHP 数值循环打开 JIT 时，最容易犯的错是只跑一次，然后看到时间变短就宣布“优化成功”。后来把同一段工作量重复跑几轮，结果会随着 PHP 版本、CLI 配置、预热状态和机器负载变化。更可靠的判断方式是：固定运行入口，分别测量关闭与开启 JIT 的中位数，再把结论带回真实业务输入。

官方地址：https://www.php.net/

PHP OPcache JIT 更适合 CPU 密集、类型相对稳定、可以重复测量的代码。它不是数据库、网络或磁盘等待的通用加速开关；评估时要先确认 CLI 的 OPcache 配置，再用多次基准结果判断收益。

先把 OPcache、JIT 和 CLI 入口分开

OPcache 负责缓存和优化 PHP 字节码，JIT 则在此基础上为部分热点代码生成本机代码。两者相关，但不是一回事：打开 OPcache 不代表 JIT 一定打开，JIT 有缓冲区也不代表当前 CLI 进程真的使用了它。

PHP 官方配置文档把 opcache.enable_cli 定义为 CLI 版本是否启用 OPcache。JIT 的开关由 opcache.jit 控制，opcache.jit_buffer_size=0 会让 JIT 不可用。PHP 8.4 又调整了默认配置：默认值变成 opcache.jit=disable 和 opcache.jit_buffer_size=64M，所以旧文章里“只填 64M 就能打开 JIT”的做法不能直接照搬。

我会把这三个条件写在命令行里，避免测试时误读了机器上的 php.ini：

# 关闭 JIT，保留 CLI 的 OPcache，作为对照组
php -d opcache.enable_cli=1 \
  -d opcache.jit=disable \
  -d opcache.jit_buffer_size=0 benchmark.php

# 开启 tracing JIT，使用明确的共享内存缓冲区
php -d opcache.enable_cli=1 \
  -d opcache.jit=tracing \
  -d opcache.jit_buffer_size=64M benchmark.php

这两条命令只改变 JIT 条件，脚本、PHP 二进制、输入规模和进程启动方式都保持一致。若你在 FPM 或 Web 请求中评估，还要单独确认对应 SAPI 的配置，不能把 CLI 结果直接当成线上请求结果。

用一段可重复的数值循环做对照

基准代码的目标不是模拟所有业务，而是让 JIT 有一块稳定、可重复的 CPU 工作。下面的循环持续更新浮点结果，避免只计算一个常量；同时保留预热样本，把初次启动和编译带来的波动与正式样本分开。

这里的 rounds、预热次数和样本数不是固定答案。我的习惯是先让单个样本达到可观察的时长，再用 7 到 15 个正式样本计算中位数；如果循环太短，测到的主要是进程调度和计时开销。

不要只看“最快一次”，要比较分布和实际收益

运行两组命令后，建议至少记录版本、配置、样本数、中位数和最大最小差异。示例中的数字只是结果记录格式，不能当作所有机器都会得到的固定提升：

我通常把“中位数下降”作为第一道信号，再看它在真实请求中占了多少时间。一个只占请求总耗时 3% 的循环，即使局部快了一倍，也很难改变用户感知；相反，长时间运行的计算任务即使只有稳定的小幅收益，也可能值得继续评估。

还要小心预热的语义：如果每次测试都新启一个 PHP CLI 进程，进程启动、配置加载和 JIT 初始化都会进入总耗时；如果是长驻进程，则应该把预热阶段和稳定运行阶段分开记录。两种测试回答的是不同问题，不能混用。

哪些代码适合测 JIT，哪些代码别急着归功于 JIT

PHP 官方 JIT RFC 的设计重点是把合适的 PHP 字节码路径转成本机代码，因此数值运算、稳定循环、长时间 CPU 计算是更自然的候选。字符串拼接、频繁对象分配、数据库查询、网络请求和磁盘读写则可能被其他成本主导。

我会按下面的顺序收敛结论：

1. 先确认热点函数确实消耗 CPU，而不是等待数据库、锁或远程服务。
2. 用生产中常见的输入规模测关闭和开启两组数据，避免只用极小样例。
3. 把 PHP 版本、CPU 架构、JIT 模式、缓冲区大小和样本统计写入基准记录。
4. 再跑一次接近真实请求的端到端压测，观察吞吐、P95/P99、内存和错误率是否一起改善。

如果只有微型循环明显变快，而接口 P95 没有变化，我不会把 JIT 当成主要优化项；如果计算任务稳定占用 CPU，且端到端指标与局部基准方向一致，再考虑在灰度环境保持配置，并为 PHP 升级保留回归脚本。

常见问题

为什么我设置了 opcache.jit_buffer_size，结果还是没有 JIT？

先检查是否启用了 CLI OPcache，以及 opcache.jit 是否仍为 disable。PHP 8.4 以后默认就是显式禁用 JIT，不能只依赖缓冲区大小。测试时把三个 -d 参数同时写出来最容易排除 ini 文件差异。

数值循环加速了，Web 接口就一定会变快吗？

不一定。接口耗时可能主要花在 SQL、网络、模板渲染或锁等待上。先用剖析结果证明数值循环是热点，再用端到端压测确认整体指标，不能用局部秒数替代请求级结论。

评估 JIT 时应该比较平均值还是中位数？

两者都可以记录，但中位数更适合先看典型样本，平均值则能暴露少数慢样本的影响。实践中我会同时保留中位数和最大值，并把异常样本单独标记，而不是只挑一个最漂亮的数字。

结语

评估 PHP OPcache JIT 的关键不是找到一个看起来惊人的百分比，而是建立一套可重复的比较：同一代码、同一输入、明确的 CLI 配置、预热后的多次样本，再回到真实请求确认收益。这样得到的结论即使是“当前不值得开启”，也比一次跑分更可靠。