PHP 性能优化实战 OPcache + FPM 极限优化配置

PHP 性能优化实战 OPcache + FPM 极限优化配置

先说下背景：这是个运行在 5 台云服务器（8 核 CPU，32GB 内存）上的老 PHP 应用。这些机器配置很强，对这个应用来说完全是过度配置了。
这事一直没有优先级，所以我从来没处理过——直到现在。
监控显示服务器使用了约 15% 的 CPU，流量增加时最高到 30%，内存使用率也很低。我知道原因：php-fpm 从来没有为这些机器正确配置过，而且 OPCache 是禁用的。
优化前后对比

优化前

• 集群：5 台云服务器
  
• 总 CPU：40 核
  
• 总内存：320GB
  
• 白天平均 CPU 负载：15-20%，峰值 30%
  
• 平均内存使用：约 2GB
  
• 平均 PHP 执行时间：150ms
  
• OPCache：关闭
  
• php-fpm 配置：
  

1. pm.max_children = 100
2. pm.start_servers = 6
3. pm.min_spare_servers = 4
4. pm.max_spare_servers = 8

复制代码

优化后

• 集群：2 台云服务器
  
• 总 CPU：16 核
  
• 总内存：64GB
  
• 白天平均 CPU 负载：约 2%
  
• 平均内存使用：约 7GB
  
• 平均 PHP 执行时间：23ms
  
• OPCache：开启
  
• php-fpm 配置：
  

1. pm.max_children = 300
2. pm.start_servers = 100
3. pm.min_spare_servers = 60
4. pm.max_spare_servers = 150

复制代码

PHP-FPM 是什么？

PHP-FPM 是最广泛使用的 PHP 应用服务方式，本质上是一个进程管理器。大多数请求遵循这个流程：
请求 -> NGINX -> php-fpm -> （选择或创建 PHP 进程）-> 执行代码 -> 响应
NGINX 作为反向代理通过 socket 与 fpm 通信——FPM 负责从进程池中选择一个进程，或者在没有空闲进程时创建新进程（如果低于定义的 max_children 值）。
例如，假设以下配置：

• 最大进程数：10
  
• 最大池大小：8
  

如果收到 8 个并发请求，php-fpm 会简单地从池中选择空闲进程。如果收到 10 个请求，它会选择 8 个空闲进程并 fork 2 个额外的进程。
Fork 进程是有开销的，但这不是世界末日。我们稍后会回到这个话题。

OPCache 是什么？

简单来说，OPCache 是一个操作码缓存。
那么什么是操作码？操作码是低级机器指令，它告诉处理器要执行什么操作。我们不需要深入这个兔子洞。当 PHP 脚本执行时会发生以下过程：

• 解释器加载脚本
  
• 脚本解析成语法树
  
• 语法树转成 Zend 引擎能懂的操作码
  
• Zend 引擎执行这些操作码
  
• 输出结果
  

当启用 OPCache 时，步骤 2 和 3 被跳过：

• 解释器加载脚本
  
• Zend 引擎执行缓存好的操作码
  
• 输出结果
  

显然，如果缓存未命中，所有步骤都必须执行。可以想象，缓存这些昂贵的操作可以提供巨大的性能改进，需要更少的 CPU 周期并减少整体内存消耗。

测试环境

我在云厂商上设置了几台机器进行测试：

• 测试服务器：4 核 CPU，8GB 内存，运行一个简单的 Laravel 应用，进行数据库读写操作
  
• 压力测试服务器：用于发送 HTTP 请求的简单服务器
  
• 数据库：2 核 CPU，4GB 内存，MySQL
  

Laravel 应用运行的代码如下：
[code]