3、OPcache加速原理：OPcache工作原理、配置参数详解与缓存预热策略

聊到PHP性能优化，OPcache绝对是个绕不开的话题。我见过太多团队，代码写得挺漂亮，服务器配置也高，但就是慢。一查，好家伙，每次请求都在重新编译PHP文件。说白了，这就是在白白浪费CPU。

今天咱们就把OPcache彻底讲透。从它怎么工作的，到每个参数该怎么调，再到缓存预热那些坑，我都会结合自己的实战经验跟你聊聊。

OPcache的工作原理

先说说它到底干了什么。

PHP是解释型语言，每次请求进来，PHP引擎都要经历三个阶段：词法分析 → 语法分析 → 编译成opcode。然后Zend引擎再执行这些opcode。你想想看，如果每个请求都重复做这三件事，那得多浪费？

OPcache的作用，就是把编译好的opcode缓存到共享内存里。下次同样的请求来了，直接拿缓存执行，跳过前面两个阶段。我做过测试，开启OPcache后，QPS能提升2到3倍，甚至更多。

嗯，这里要注意一点：OPcache只缓存opcode，不缓存执行结果。所以像数据库查询结果、API响应这些，它管不了。别指望它能替代Redis或Memcached。

配置参数详解

接下来咱们一个一个看。这些参数我调过无数次，有些坑是真的踩过。

opcache.enable

这个最简单，就是个开关。1表示开启，0表示关闭。生产环境必须开，没得商量。

opcache.enable=1

我记得有一次，同事说服务器性能突然下降，查了半天，发现是部署脚本不小心把这个参数改成了0。从那以后，我习惯在部署脚本里加个检查，确保这个值不会被意外覆盖。

opcache.memory_consumption

这个参数控制OPcache能用的共享内存大小，单位是MB。默认是64MB，但说实话，这个值对大多数项目来说都偏小。

怎么调？我有个经验公式：

• 小型项目（几百个文件）：64MB - 128MB
• 中型项目（几千个文件）：128MB - 256MB
• 大型项目（上万个文件）：256MB - 512MB

我的建议是：先设个128MB，跑一段时间，用opcache_get_status()查看memory_usage。如果used_memory接近free_memory，就适当调大。反之，如果用了不到一半，就调小。

opcache.max_accelerated_files

这个参数控制最多能缓存多少个PHP文件。默认值是2000，但很多项目都不止这个数。

怎么算？我一般用这个命令统计项目里的PHP文件数：

find . -name "*.php" | wc -l

然后把这个数字稍微放大一点，比如乘以1.2。为什么？因为有些框架会在运行时动态加载文件，你得留点余量。

如果这个值设得太小，会发生什么？新文件进来，旧文件被踢出缓存。然后旧文件再次被请求时，又得重新编译。这就是所谓的「缓存抖动」，性能反而会下降。

其他重要参数

php -r 'opcache_reset();'

sudo systemctl reload php-fpm

缓存预热策略

这个很多人会忽略。你想想看，刚部署完代码，OPcache里是空的。第一个用户访问时，PHP得编译所有文件，那响应时间会特别慢。这就是所谓的「冷启动」问题。

缓存预热，就是在服务启动后，主动把常用文件加载到OPcache里。我常用的方法有几种：

方法一：脚本预热

写个PHP脚本，遍历项目目录，用include或require加载所有文件。这样OPcache就会自动缓存它们。

// warmup.php
$files = new RecursiveIteratorIterator(
    new RecursiveDirectoryIterator('/path/to/project')
);

foreach ($files as $file) {
    if ($file->getExtension() === 'php') {
        // 加载文件，触发OPcache缓存
        include $file->getRealPath();
    }
}

echo "Warmup complete: " . memory_get_usage() . " bytes\n";

然后部署完成后执行：

php warmup.php

方法二：curl请求预热

如果你的项目是API或Web应用，可以用curl模拟请求，让OPcache在真实请求中完成预热。

#!/bin/bash
# warmup.sh
URLS=(
    "https://your-site.com/"
    "https://your-site.com/api/health"
    "https://your-site.com/login"
)

for url in "${URLS[@]}"; do
    curl -s -o /dev/null "$url"
done

echo "Warmup done"

这个方法的好处是，能覆盖到框架的路由、中间件等动态加载的文件。缺点是比较慢，而且可能产生脏数据（比如写日志）。

方法三：结合部署工具

如果你用Ansible、SaltStack或Kubernetes，可以在部署流程里加一个预热步骤。比如在K8s的postStart钩子里执行预热脚本。

lifecycle:
  postStart:
    exec:
      command: ["php", "/var/www/html/warmup.php"]

监控与调优

配置好了，怎么知道它跑得怎么样？我习惯用这几个命令：

# 查看OPcache状态
php -r 'print_r(opcache_get_status(false));'

# 查看配置
php -r 'print_r(opcache_get_configuration());'

重点关注这几个指标：

• cache_hits / cache_misses：命中率应该超过95%。如果低于90%，说明配置有问题
• memory_usage.used_memory：看看内存用了多少，别超过80%
• opcache_statistics.num_cached_keys：缓存的文件数，别超过max_accelerated_files

好了，关于OPcache就聊这么多。下一章咱们会讲PHP-FPM的进程管理，那又是一个能挖出不少性能提升空间的地方。到时候见。