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 配置：
pm.max_children = 100
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 8优化后
[*]集群：2 台云服务器
[*]总 CPU：16 核
[*]总内存：64GB
[*]白天平均 CPU 负载：约 2%
[*]平均内存使用：约 7GB
[*]平均 PHP 执行时间：23ms
[*]OPCache：开启
[*]php-fpm 配置：
pm.max_children = 300
pm.start_servers = 100
pm.min_spare_servers = 60
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 应用运行的代码如下：
页:
[1]