PHP-FPM并发瓶颈在max_children配置不当、进程复用不足及空闲回收过激，导致请求排队；MySQL需持久连接与合理wait_timeout；Redis应启用连接池；Swoole协程须全链路非阻塞改造。
PHP-FPM 进程模型与并发瓶颈在哪
PHP 本身是同步阻塞的，高并发压力下卡在 max_children 和 pm.max_requests 配置上。不是 PHP 慢，而是默认的 pm = dynamic 模式下子进程复用不充分、空闲进程回收过激，导致请求排队等 php-fpm.sock 可用连接。
-
pm.max_children不是越大越好：超过系统可用内存（比如每个 worker 占 30MB，设 100 就要 3GB），会触发 OOM Killer 杀进程 -
pm.start_servers建议设为min_spare_servers和max_spare_servers的中间值，避免冷启动抖动 - 把
request_terminate_timeout从 0 改成30s，防止单个慢脚本拖垮整个池
MySQL 连接池与长连接失效问题
PHP-FPM 每个 worker 是独立进程，mysqli 或 PDO 默认不复用连接，频繁 new PDO() 会导致 MySQL 的 max_connections 快速打满，甚至出现 Too many connections 错误。
- 用
PDO::ATTR_PERSISTENT => true开启持久连接，但注意它只在单个 worker 生命周期内复用，不是跨 worker 共享 - 避免在循环里反复
new PDO()，应把连接实例化提到函数外或用依赖注入容器管理 - MySQL 端需调大
wait_timeout（默认 28800 秒），否则空闲连接被服务端断开后，PHP 下次用会报MySQL server has gone away
Redis 作为缓存层时的连接管理陷阱
直接用 new Redis() + connect() 在每次请求中建连，会在高并发下产生大量 TIME_WAIT 状态连接，耗尽本地端口，同时 Redis 服务端也面临连接数压力。
- 用
Predis\Client并配置'scheme' => 'tcp'+'connection_timeout' => 0.2，比原生扩展更可控 - 务必启用连接池：Laravel 的
phpredis扩展不自带池，得靠RedisCluster或 Swoole 的Swoole\Coroutine\Redis；否则建议改用phpredis的pconnect()（注意它不支持所有命令，如SELECT） - 缓存 key 务必加统一前缀（如
cache:article:123），避免不同环境 key 冲突，也方便redis-cli --scan --pattern "cache:*" | xargs redis-cli del清理
Swoole 协程改造的关键取舍点
想突破 PHP-FPM 的并发天花板，Swoole 是主流选择，但不是“装上就变快”。协程模型要求整个调用链路非阻塞，而多数传统扩展（如 mysql_connect()、file_get_contents()）仍是同步的。
立即学习“PHP免费学习笔记（深入）”；
- 必须用
Swoole\Coroutine\MySQL替代mysqli，用Swoole\Coroutine\Redis替代Redis类，否则协程会退化成同步等待 -
Co::sleep()替代sleep()，Co::httpGet()替代file_get_contents()，否则协程调度器无法切走 - 不要在协程里调用
exec()、shell_exec()等阻塞系统调用，它们会让整个 Worker 进程卡住
use Swoole\Coroutine\MySQL;$mysql = new MySQL(); $mysql->connect([ 'host' => '127.0.0.1', 'user' => 'root', 'password' => '123456', 'database' => 'test', ]); $result = $mysql->query('SELECT * FROM user WHERE id = 1');
真实高并发场景里，最常被忽略的是日志写入和配置热加载——error_log() 直写文件在每秒上千请求时会成为 I/O 瓶颈，而 opcache.revalidate_freq=2 导致每次修改代码都要等 2 秒才生效，调试时误以为是逻辑问题。
