PHP在Ubuntu上的优化技巧

Ubuntu 上 PHP 性能优化实用指南

PHP 项目的性能瓶颈往往不在语言本身，而在于环境配置和部署姿势。尤其在 Ubuntu 这类广泛使用的服务器系统上，稍作调优就能带来肉眼可见的响应速度提升。下面这些方向，是经过大量线上实践验证过的“高性价比”优化路径。

一、基础准备与版本选择

首先是 PHP 版本的选择——这几乎是零成本、高回报的第一步。建议直接上 8.2（或更新的稳定版），每次大版本迭代带来的性能提升都很可观。安装可以通过 ppa:ondrej/php 这个维护得很好的第三方源搞定：

sudo add-apt-repository ppa:ondrej/php && sudo apt update && sudo apt install php8.2 php8.2-cli php8.2-fpm php8.2-{bz2,curl,mbstring,intl}

当然，生产环境上线前一定要先在测试环境中跑一遍兼容性验证，避免扩展或代码在新版本下翻车。

SAPI 方面，优先选择 PHP-FPM，而不是传统的 mod_php。FPM 在进程管理和并发控制上都更灵活，配合 Nginx 作为前端 Web 服务器，在高并发场景下比 Apache + mod_php 的组合更有优势。Web 层推荐 Nginx + PHP-FPM 的经典搭配，这也是当前业界的标准选择。

二、字节码缓存：OPcache 必配

字节码缓存是性价比最高的优化项，没有之一。PHP 每次请求都要重新编译脚本，而 OPcache 能把编译后的字节码直接存在共享内存里，省掉大量重复劳动。安装很简单：

sudo apt install php-opcache

之后在对应 php.ini（如 /etc/php/8.2/fpm/php.ini 或 CLI 的 php.ini）中开启并调优，下面是一组经过生产检验的推荐配置：

• zend_extension=opcache.so
• opcache.enable=1
• opcache.enable_cli=1（开发调试用，生产按需）
• opcache.memory_consumption=128M
• opcache.interned_strings_buffer=8
• opcache.max_accelerated_files=10000
• opcache.validate_timestamps=1（开发）或 60（生产）
• opcache.revalidate_freq=60
• opcache.fast_shutdown=1

配置完成后记得重启 FPM 服务，让配置生效：

sudo systemctl restart php8.2-fpm

一个常见的误区是只装不调，结果内存缓存太小导致频繁驱逐，效率大打折扣。所以上面的参数值得花点心思按实际项目规模去微调。

三、PHP-FPM 进程与请求调优

FPM 的进程管理是性能的核心控制点。编辑 /etc/php/{version}/fpm/pool.d/www.conf，推荐用 dynamic 模式，根据服务器内存和负载按公式计算。下面是一组适合中等流量站点的初始配置：

• pm = dynamic
• pm.max_children —— 具体数值需通过内存预算计算（见下一节）
• pm.start_servers = 5
• pm.min_spare_servers = 5
• pm.max_spare_servers = 35
• pm.max_requests = 500 —— 避免内存泄漏累积
• request_terminate_timeout = 30s —— 防止慢请求拖垮进程
• slowlog = /var/log/php8.2-fpm.slow.log
• request_slowlog_timeout = 10s —— 超过 10 秒的请求记录到慢日志

另外建议开启 FPM 状态页：pm.status_path = /status，配合 Nginx 做访问限制（只允许内网或监控 IP），方便实时观测进程队列和响应时延，做容量评估和健康检查。变更配置后同样要重启 PHP-FPM。

四、计算 max_children 与内存预算

这个公式是老生常谈，但很多人仍然凭感觉设置：

max_children ≤ 可用内存 / 单进程峰值内存

具体步骤：

1. 观测单进程峰值内存：可以在 FPM 池配置中临时启用 slowlog，或者用监控工具（如 htop、New Relic）在压测下抓取每个 PHP-FPM 进程的峰值 RSS。
2. 预留系统与其他服务内存：操作系统、数据库、缓存（Redis/Memcached）、Web 服务器等都需要吃内存。通常预留 1-2GB 给它们。
3. 代入计算：比如可用内存 8GB，单进程峰值 80MB，则 max_children 上限大约为 (8 - 2) × 1024 / 80 ≈ 76。然后结合实际并发目标和响应时间再微调。
4. 根据场景切换模式：如果并发较低，更希望快速回收空闲进程，可以考虑 ondemand 模式，按需拉起子进程，节省常驻内存。

这里想强调一点：不要只看平均值，要盯住峰值。线上经常出现瞬时尖峰把进程打满，然后整个队列积压。所以 max_children 设得宽裕一些的同时，也要配合 nginx 的限流和超时策略。

五、数据与 Web 层优化及监控落地

深入到数据层和 Web 层，优化的空间更大。

数据层与缓存

Redis / Memcached 几乎是标配。页面片段缓存、全页缓存、会话存储、甚至数据库查询结果缓存，都能显著降低数据库压力。另外，对于连接频繁的场景，可以考虑在 PDO 或 MySQLi 中启用 持久连接（persistent 选项），减少每次握手和认证的开销。

Web 服务器与传输

如果用的是 Nginx，几个小动作收益明显：开启 Gzip 压缩、合理配置 worker_processes（通常等于 CPU 核心数）、调整 worker_connections 和 keepalive_timeout。最重要的一点：让 Nginx 直接处理静态资源（CSS、JS、图片等），PHP-FPM 只处理动态请求，这样能极大减少 PHP 进程的无效消耗。

如果用的是 Apache，可以启用 KeepAlive、mod_expires（设置缓存过期头）、mod_deflate（压缩传输），减少慢速连接和重复传输的开销。

代码与架构层面

一些常见的“性能杀手”：滥用 eval、过多的全局变量、深层嵌套循环。对于大文件或大数据集的处理，优先使用 生成器 和 分块处理，避免一次性把全部数据加载到内存。在代码中合理使用 unset 释放大变量，必要时可以手动调用 gc_collect_cycles 来强制回收循环引用。这些小习惯积累起来，对峰值内存的改善非常明显。

监控与诊断

没有监控的优化等于蒙眼开车。先打开 PHP-FPM 的 慢日志，找出响应最慢的端点。更进一步，可以使用 Blackfire、New Relic、XHProf 等性能剖析工具，定位到底是哪一段代码拖了后腿。系统层面，配合 htop、vmstat、iostat 和 php-fpm status 持续观测队列长度、进程数和响应时延，然后根据这些数据动态回调 FPM、OPcache 甚至数据库的配置。这正是“调优—观测—再调优”的闭环。