PHP 每次请求都需要加载并编译脚本，OPcache 把编译后的字节码保存在共享内存中，减少重复解析成本。它通常是生产 PHP 服务最直接的性能收益，但配置必须与代码规模和发布方式匹配。

核心原则

  • 确认生产 SAPI 已加载 OPcache，并通过受保护的状态页或指标验证命中率。
  • 根据脚本数量设置 max_accelerated_files，避免哈希表容量不足频繁重启。
  • 根据已用内存与浪费比例调整 memory_consumption，预留合理增长空间。
  • 发布模式可靠时可以降低时间戳检查频率，但必须提供明确的缓存刷新步骤。
  • 预加载只适合稳定且可控的核心代码，配置变更后需要重启相应 PHP 进程。

推荐的实践步骤

先采集命中率、缓存脚本数、可用内存和重启原因作为基线，再逐项调整。常见目标是保持较高命中率且不发生内存耗尽重启。发布采用原子目录切换时，应在新版本就绪后重载 PHP-FPM；不要开放公网脚本让任意请求调用 opcache_reset。

opcache.enable=1
opcache.memory_consumption=192
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

示例用于说明实现思路，实际项目还应结合所使用的框架版本、部署环境和业务约束进行调整。重要配置要进入版本管理，并在测试环境验证后再发布。

常见误区

  • 只看请求速度、不监控缓存重启和浪费内存，会掩盖配置容量问题。
  • 关闭时间戳验证却没有发布重载流程，可能继续运行旧代码。
  • 把 OPcache 状态页暴露到公网，会泄露文件路径和运行信息。

上线前检查清单

  • 确认“确认生产 SAPI 已加载 OPcache，并通过受保护的状态页或指标验证命中率”已经通过代码审查或运行验证。
  • 确认“根据脚本数量设置 max_accelerated_files，避免哈希表容量不足频繁重启”已经通过代码审查或运行验证。
  • 确认“根据已用内存与浪费比例调整 memory_consumption，预留合理增长空间”已经通过代码审查或运行验证。
  • 确认“发布模式可靠时可以降低时间戳检查频率，但必须提供明确的缓存刷新步骤”已经通过代码审查或运行验证。
  • 为失败路径、边界条件和回滚方案准备测试或演练记录。
  • 上线后观察错误率、延迟和资源消耗，确认变化符合预期。

总结

PHP OPcache 性能优化：配置、监控与排错的关键在于把隐含假设变成可执行的约束，并通过测试、监控和复盘持续验证。先从影响最大的真实场景开始，小步调整并保留回滚能力，通常比一次性大范围改造更安全，也更容易积累可复用的工程经验。