在 Ubuntu 上部署 PHP 应用时，性能下降往往不是某一个参数配置错了，而是请求链路上多个环节同时放大了延迟。本文按代码执行、数据库交互、PHP-FPM、缓存、系统资源和 Web 服务器协同几个层面拆开看，帮助你判断瓶颈到底落在 CPU、内存、I/O 还是外部依赖上，也方便后续按优先级排查。
代码层：先排查脚本本身有没有把 CPU 吃满
很多 PHP 性能问题，第一现场就在业务代码里。即使服务器配置不差，只要代码路径里存在低效操作，请求时间和 CPU 占用都会被直接拉高。
老旧 PHP 版本会先吃掉一部分性能红利
如果还在使用偏旧版本的 PHP，本身就可能错过不少运行时优化。比如 PHP 8.x 引入的 JIT 编译器，在部分场景下可以带来明显性能提升。升级不一定能立刻解决所有问题，但它通常是性能优化里成本相对明确的一步。
重复计算和低效循环会拉长执行时间
常见问题包括冗余循环、重复计算，以及对大数据集进行多层嵌套遍历。这类写法在数据量小时不明显，一旦请求量上来，CPU 使用率就会迅速升高。相比单纯加机器，先减少无意义计算，收益通常更直接。
全局变量使用过多也会增加内存压力
频繁操作全局变量会让变量在脚本生命周期内持续占用内存，直到脚本结束才释放。对于执行时间较长、逻辑较复杂的 PHP 请求，这类内存占用会进一步放大资源压力。
数据库层：PHP 很多时候是在等待数据库返回
PHP 应用响应慢，不一定是 PHP 真在“算得慢”，也可能是在等数据库。只要 SQL 执行不顺，应用端就只能阻塞等待，最终表现为页面响应变慢、并发能力下降。
慢 SQL 往往来自索引和查询结构问题
最常见的数据库瓶颈是慢查询：没有走索引、使用了复杂的 JOIN，或者直接触发全表扫描。这样一来，数据库负载会被快速抬高，请求处理时间也会被数据库响应时间拖长。
连接频繁创建、不复用，会白白增加开销
如果每次请求都频繁建立数据库连接，又没有做好复用，连接建立本身就会成为额外负担。对于访问量较高的 PHP 服务，这种连接开销会不断叠加，影响整体吞吐。
表结构不合理会让后续优化越来越难
除了 SQL 语句本身，数据库结构设计也很关键。缺少合适索引、表结构没有针对查询模式优化，都会让数据库在高负载下更容易成为瓶颈。这类问题往往不会只影响一个接口，而是会波及整站多个功能。
PHP-FPM：进程参数不匹配时，吞吐和内存都会出问题
PHP-FPM 是 Ubuntu 上运行 PHP 的核心进程管理组件，参数配置是否贴合机器资源，直接决定了并发处理能力和内存利用效率。
pm.max_children 需要在并发和内存之间取平衡
pm.max_children 设得太大，会导致内存压力陡增；一旦物理内存不足，就可能频繁使用 Swap，性能明显下滑。设得太小，则高并发下可用工作进程不够，请求只能排队等待，吞吐上不去。
空闲进程参数没调好，会增加额外 CPU 开销
pm.start_servers、pm.min_spare_servers、pm.max_spare_servers 这几个参数如果没有按照服务器资源和访问波峰来调整，进程就可能频繁创建和销毁。这样的抖动会制造额外 CPU 开销，也会让响应时间更不稳定。
request_terminate_timeout 过长会拖住资源
如果 request_terminate_timeout 设置过长，长时间运行的脚本会一直占着 PHP-FPM 进程不释放。对少量慢请求来说这可能只是拖尾问题，但在并发上来后，整个进程池都可能被拖慢。
缓存机制：没有缓存，请求就会反复做同样的事
缓存缺失是 PHP 应用性能下降里最容易被忽视、但影响范围很广的一环。没有缓存时，同样的计算、查询和资源传输会在每个请求里重复发生。
没开 OPcache，请求会重复编译 PHP 脚本
如果没有启用 OPcache，每次请求都需要重新编译 PHP 脚本，CPU 负载自然会升高。这部分开销在访问量增加时会被放大，尤其对代码量较大的项目更明显。
业务数据不做缓存，数据库会持续承压
像数据库查询结果、配置类静态数据、频繁读取的公共信息，如果没有借助 Redis 或 Memcached 做缓存，应用就会反复访问数据库。短期看是接口变慢，长期看则会把数据库推成全局瓶颈。
浏览器缓存缺位，会让静态资源重复下载
浏览器端缓存如果没有配置，静态资源每次请求都需要重新下载。这不仅增加网络传输负担，也会让前端加载速度变慢，最终影响用户体感。
系统资源与 Web 服务器：最后决定上限的是整机协同能力
当代码、数据库和 PHP-FPM 都存在一定压力时，Ubuntu 系统资源和 Web 服务器配置就会决定性能上限。很多“看起来像 PHP 慢”的现象，本质上是资源协同没有调顺。
内存、CPU、磁盘 I/O 都可能成为硬瓶颈
内存不足时，若 memory_limit 设得过高，或者应用本身存在内存泄漏，就容易频繁使用 Swap，性能会明显打折。高并发场景下，CPU 过载会直接拉低请求处理速度；而频繁读写文件，例如日志写入不合理、大量小文件读写，也会让磁盘 I/O 等待时间拖慢整个流程。
Web 服务器与 PHP-FPM 配合不当，同样会影响响应时间
Nginx 或 Apache 如果没有和 PHP-FPM 配合好，前端请求处理效率也会下降。比如没有开启 Gzip 压缩，传输数据量更大，网络延迟会上升；PHP-FPM 的监听方式如果选择不当，也会影响通信效率。通常 Unix Socket 比 TCP Socket 更快，但前提是权限配置正确。
Worker 参数和 CPU 核心数需要匹配
以 Nginx 为例，worker_processes 如果没有按 CPU 核心数调整，计算资源就可能无法被充分利用。看似只是一个 Web 服务器参数，实际会直接影响整机对并发请求的承载能力。
第三方扩展与外部服务：别忽略链路里的“隐性拖慢项”
有些性能问题不在主业务代码，而是藏在扩展、依赖服务和文件系统选择里。这类问题不一定天天触发，但一旦出现，定位通常更费时间。
无用扩展会占内存，还可能制造冲突
安装过多不必要的 PHP 扩展，例如过时的数据库驱动或调试工具，不仅会占用额外内存，也可能带来兼容性和稳定性问题。对线上环境来说，保留真正需要的扩展更稳妥。
外部 API 慢，PHP 只能被动等待
如果应用依赖支付接口、第三方数据服务等外部 API，而这些服务响应慢，PHP 请求就会被同步阻塞。最终表现出来的仍然是接口超时、进程占满、吞吐下降，但根因其实在外部链路。
文件系统选择和缓存策略也会影响读写效率
文件系统没有针对业务场景优化，同样会拖累性能。比如文中提到的 ext4 与 XFS 选择，以及文件系统缓存是否启用，都会影响文件读写速度。对于日志量大、临时文件多的应用，这部分差异会更加明显。
怎么判断该先查哪一层
如果 Ubuntu 上的 PHP 服务出现性能下降，最实用的思路不是一次性改所有配置，而是先判断时间到底耗在哪一段。CPU 长时间高负载，优先看代码路径、循环和 PHP 版本；数据库等待时间长，优先查 SQL、索引和连接复用；PHP-FPM 进程频繁打满，就回头检查 pm.max_children 及空闲进程参数；如果资源已经逼近上限，再看内存、Swap、磁盘 I/O 与 Web 服务器协同。
换句话说，PHP 性能优化在 Ubuntu 上更像一套分层排查过程，而不是单纯调一个参数。把代码、数据库、FPM、缓存和系统资源按链路串起来看，通常比孤立地盯着某一项配置更有效。
