PHP 8.3 JIT 编译器性能调优：CPU 密集型任务的配置实战

JIT 不是给所有 PHP 请求“免费加速”的开关。对于 WordPress 常见的数据库查询、模板渲染、远程请求和磁盘读写，瓶颈通常不在 PHP 指令执行；但在批量数据计算、复杂规则处理、统计聚合、生成缩略图前的像素级运算等 CPU 密集型任务中，PHP 8.3 的 JIT 值得单独评估。

先确认：JIT 优化的是 CPU 计算，不是整个网站

OPcache 的核心工作，是将 PHP 源码编译后的字节码缓存起来，避免每次请求重新解析和编译。JIT 则更进一步：在运行时把部分 PHP 字节码编译为更接近机器执行方式的代码。

这意味着，JIT 的收益取决于代码是否长期消耗 CPU。一个请求如果大部分时间都在等待数据库、调用 HTTP 接口、读取文件或执行 WordPress 钩子链，JIT 即使启用，响应时间也未必有肉眼可见的变化。反过来，如果某段 PHP 代码反复执行大量数值运算、循环判断或递归调用，JIT 才可能减少解释执行的开销。

对于数值计算、数列生成等大量循环场景，参考资料给出的预期改善区间约为 20%～30%。这应当被视为基准测试的观察目标，而不是上线前可以承诺的固定结果。实际收益仍会受到 CPU、PHP-FPM 进程生命周期、代码分支复杂度和数据结构的影响。

推荐起点：1255 与 64M 缓冲区

在 PHP 8.3 的 php.ini 中，可以先采用下面这组配置作为 CPU 密集型任务的测试起点：

opcache.enable=1
opcache.jit_buffer_size=64M
opcache.jit=1255

opcache.jit_buffer_size 用于预留存放 JIT 编译代码的共享内存。该值为 0 时，JIT 实际处于禁用状态；因此只设置 opcache.jit=1255 而没有可用缓冲区，并不能完成启用。

64M 是适合先行验证的保守起点。JIT 缓冲区并不是越大越好：如果站点没有足够多的热点计算代码，额外预留的共享内存只会增加资源占用。配置时还应确保它与 OPcache 的整体共享内存规划相匹配，而不是在内存紧张的环境中盲目扩大。

opcache.jit=1255 是一个数值模式配置。其关键点在于启用 tracing 路径的编译策略，并使用较积极的优化级别。PHP 文档中将 1254 标为 tracing 模式，而 1255 在此基础上提高了脚本整体优化级别。对包含长循环、稳定执行路径和重复运算的代码而言，tracing 更有机会将高频路径编译起来。

如果基准测试通过 CLI 执行，还需要额外开启 CLI 的 OPcache，否则命令行结果不能代表 JIT 已启用：

opcache.enable_cli=1

修改配置后，应重启对应的 PHP 运行进程，再进行测试。不要只修改 php.ini 就直接对比，否则很容易测到旧配置或未生效的运行环境。

用同一段代码对比关闭与开启 JIT

下面的示例刻意分成两类任务：第一类是纯数值循环，第二类是数组求和。它们的差异正好能说明 JIT 的适用边界。

<?php

function elapsed(callable $callback): float
{
    $start = hrtime(true);
    $callback();
    return (hrtime(true) - $start) / 1e9;
}

$iterations = 5_000_000;

$numericTime = elapsed(function () use ($iterations): void {
    $result = 0.0;

    for ($i = 1; $i <= $iterations; $i++) {
        $result += ($i * 1.17) / ($i + 0.31);
    }

    echo "数值计算结果：{$result}n";
});

$arrayTime = elapsed(function () use ($iterations): void {
    $numbers = range(1, $iterations);
    $result = array_sum($numbers);

    echo "数组求和结果：{$result}n";
});

echo "数值循环耗时：{$numericTime} 秒n";
echo "数组求和耗时：{$arrayTime} 秒n";

先在 JIT 关闭的环境中执行。最直接的方式是临时设置：

opcache.jit_buffer_size=0

记录数值循环和数组求和的耗时后，再启用：

opcache.jit_buffer_size=64M
opcache.jit=1255
opcache.enable_cli=1

每种配置应连续执行多次，再比较相近结果。第一次运行可能包含初始化和编译成本，不能只拿单次结果下结论。

如何理解循环与数组操作的差异

数值循环中的乘法、除法、加法和分支判断，主要由 PHP 用户态代码持续执行，属于 JIT 更容易发挥作用的区域。对于这类重复次数很高的任务，若测试结果接近 20%～30% 的耗时下降，说明当前代码和运行环境具备一定的 JIT 优化空间。

数组求和则不同。array_sum() 本身属于 PHP 内部实现的函数，重点工作并不等同于“解释执行一大段 PHP 循环”。数组创建、内存分配、哈希表或连续数据访问，以及内部函数调用成本，都可能成为主要影响因素。JIT 不会把数组操作自动变成零成本，也不会绕过内存访问。

因此，数组操作测试可能出现几种结果：

• 数值循环明显变快，数组求和变化很小；
• 两者都有改善，但数组部分改善幅度低于纯计算循环；
• 数组规模较大时，内存分配与数据搬运占主导，JIT 几乎没有显著影响。

这不是 JIT “失效”，而是说明瓶颈不在它能解决的层面。若 WordPress 插件中的热点任务主要是大数组拼装、序列化、数据库结果处理或字符串拼接，应该先检查数据结构和算法，不能期待仅靠 opcache.jit=1255 获得稳定百分比提升。

在 WordPress 开发中的落地方式

不要一上来就给整个生产站点启用 JIT，然后用首页加载时间判断成败。更可靠的做法，是先定位真正的 CPU 热点。

例如，自定义插件中可能存在批量计算内容评分、导入时清洗大量数据、根据规则生成统计字段，或在后台任务中反复处理数值。这类代码适合抽成独立脚本或 WP-CLI 任务，在相同数据集、相同 PHP 版本和相同服务器上做开关对比。

判断是否值得保留 JIT，可以看三个问题：

1. 热点代码是否存在大量重复的 PHP 循环、数值运算或较深的函数调用链。
2. 开启后，目标任务的稳定耗时是否确实下降，而不是只在单次运行中偶然变快。
3. JIT 缓冲区是否保持可用，且没有为了少量收益挤压站点原本需要的 OPcache 内存。

如果改善只出现在离线统计或后台批处理任务中，也完全可以把收益集中在这些任务上，而不必把它当成前台页面性能方案。对 WordPress 而言，缓存策略、数据库查询、图片处理链路和插件调用成本，通常仍需要分别优化。

1255 + 64M 是一个适合验证的起点，不是通用生产答案。先用真实的 CPU 密集型代码测出循环任务是否接近预期的 20%～30% 改善，再决定是否将这项配置保留在正式环境中。