Ubuntu 上的 PHP 应用一旦并发上来，最常见的问题并不是“PHP 太慢”，而是进程数、内存、脚本缓存和 Web 服务器配合失衡。要把吞吐量提上去，不能只盯着一个配置项，而要从 PHP-FPM、php.ini、Nginx/Apache 以及监控手段一起看。

下面按照实际运维中更常见的调整顺序，整理一套适合 Ubuntu 环境的优化思路。你可以先从进程模型和缓存入手，再结合日志与资源监控确认瓶颈，最后再决定是否需要上负载均衡或升级硬件。

先看 PHP-FPM：并发能力的第一层开关

如果你的 PHP 服务是跑在 PHP-FPM 上，首先应该检查进程池配置。对应文件通常是：

/etc/php/7.x/fpm/pool.d/www.conf

其中 7.x 需要替换成你的 PHP 版本。

这里最关键的是 pm 以及一组子进程数量参数。把 pm 设置为 dynamic 或 ondemand，PHP-FPM 才能根据负载变化创建或回收子进程；如果参数太保守，高并发时请求很容易在队列里堆积。

关键参数怎么理解

• pm = dynamic：适合常见 Web 服务场景，预留一定数量的工作进程，响应更稳定。
• pm = ondemand：更偏节省资源，进程按需拉起，适合低峰高闲置场景。
• pm.max_children：允许同时处理请求的最大子进程数，是并发上限的重要约束。
• pm.start_servers：服务启动时预创建的子进程数量。
• pm.min_spare_servers 与 pm.max_spare_servers：控制空闲进程池范围，避免高峰来临时临时扩容过慢，或低峰时占用过多内存。

可参考这样的配置：

pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35

这组数值并不是通用标准，但它说明了一个思路：先给出明确的并发承载上限，再控制启动进程和空闲进程数量，避免既抢内存又顶不住流量。

再补足内存和 OPcache，减少请求执行成本

当 PHP-FPM 进程数提上去之后，第二个要看的就是单个请求的资源开销。如果每个 PHP 进程本身就很重，那么即使 pm.max_children 调大，系统也可能很快被内存吃满。

适当提高 PHP 内存限制

可以编辑：

/etc/php/7.x/cli/php.ini

将 memory_limit 提高，例如：

memory_limit = 256M

这一项的重点不是“越大越好”，而是让应用在真实负载下不至于频繁触发内存不足，同时又不要把单进程上限放得过于夸张，否则会直接压缩可用并发数。

启用 OPcache 提升脚本执行效率

OPcache 对 PHP 并发能力的帮助通常非常直接，因为它减少了脚本重复编译带来的额外开销。要确认 php.ini 中已经启用，并且有合理配置，例如：

zend_extension=opcache.so
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60

其中：

• opcache.memory_consumption=128：为字节码缓存分配内存。
• opcache.interned_strings_buffer=8：为 interned strings 预留空间。
• opcache.max_accelerated_files=4000：决定可缓存脚本文件数量。
• opcache.revalidate_freq=60：控制文件更新时间检查频率。

如果业务代码量不小，但 OPcache 空间偏紧，缓存命中率上不去，那么单次请求的 CPU 开销就会偏高，并发自然也难上去。

别忽略入口层：Apache 或 Nginx 也会卡住并发

PHP 并发问题不一定都发生在 PHP-FPM 本身，前端 Web 服务器同样可能成为瓶颈。

Apache 场景

如果你使用的是 Apache，需要确认 mpm_prefork_module 或 mpm_event_module 的配置是否合理。不同 MPM 模式对连接处理方式不同，错误的配置会让请求在进入 PHP 之前就开始排队。

Nginx 场景

如果你使用的是 Nginx，应重点检查 worker_processes 和 worker_connections。示例配置如下：

worker_processes auto;
events {
    worker_connections 1024;
}

worker_processes auto; 会让 Nginx 根据 CPU 核心数自动分配工作进程，worker_connections 1024; 则定义单个 worker 可处理的连接数量。前端连接能力太小，即使后端 PHP-FPM 还有余量，整体吞吐也上不去。

单机顶不住时，再考虑负载均衡横向扩展

如果单台服务器已经把 PHP-FPM、OPcache 和 Web 服务器都调到比较合理的状态，但高峰期仍然吃紧，就该考虑把流量分散出去。

常见做法是使用负载均衡器，例如 HAProxy 或 Nginx，把请求分发到多台 PHP 应用服务器。这样做的价值不只是提高总并发，还能降低单点故障风险，让扩容方式从“继续堆单机参数”变成“增加节点”。

这一步通常适合这些场景：

• 单机 CPU、内存已经接近上限；
• 优化后高峰时延仍然明显升高；
• 业务流量波动大，单机参数调整空间有限。

用监控、代码优化和硬件升级收尾

参数调优只能解决一部分问题。真正要把并发能力稳定下来，最后还得回到监控、代码和硬件三个层面。

先用监控和日志确认瓶颈

可以用这些工具直接看系统资源占用：

top
htop
vmstat

同时分析 PHP 错误日志和访问日志，确认到底是 CPU 打满、内存不够、磁盘 I/O 紧张，还是某类请求本身过慢。没有这一层验证，参数调整很容易变成盲调。

代码和缓存机制往往比调参数更有效

如果应用里存在重复计算、低效循环或者过多数据库查询，那么光调服务器参数只能延后问题暴露的时间。更直接的做法包括：

• 优化 PHP 代码路径，减少不必要的计算；
• 减少重复数据库查询；
• 使用 Redis 或 Memcached 之类的缓存机制，降低数据库压力。

软件优化接近极限后，再考虑升级硬件

如果已经完成应用层和服务层优化，服务器仍然吃紧，就需要评估硬件是否成为根本约束，例如 CPU、内存或存储设备性能不足。这个阶段继续微调参数的收益通常已经不高，直接升级硬件会更实际。

配置改完别忘了让服务真正生效

最后还有一个经常被忽略的细节：修改完 PHP、PHP-FPM、Nginx 或 Apache 相关配置后，要重启对应服务，否则新参数不会真正投入运行。

因此，一轮完整优化至少应该包含三步：修改配置、重启服务、观察负载变化。只有这样，才能判断这次调整到底是在提升并发，还是只是把瓶颈从一个地方挪到了另一个地方。