FPM在高IO场景QPS卡在50–200是因同步阻塞模型导致worker进程挂起占内存，如1000 QPS×80ms需80个worker、耗4.8GB内存；Hyperf通过协程调度、常驻内存和连接池复用提升吞吐，但需正确配置server类型、禁用阻塞函数、合理设置连接池及异步队列参数。
传统 PHP-FPM 在高并发 IO 场景下卡在 50–200 QPS 是常态，不是代码写得差，而是模型本身扛不住——worker_num 拉到 200，内存直接爆掉，max_children 超过 50 就开始频繁 OOM。Hyperf 不是“换个框架就变快”，它靠协程调度 + 常驻内存 + 连接池复用，把单机吞吐从百级拉到万级，前提是配置和写法都得对。
为什么 FPM 在 IO 密集时 QPS 上不去？
不是 CPU 不够，是每个请求都在等 DB、Redis、HTTP 调用返回，期间进程挂起、占内存、不干活。1000 QPS × 平均 80ms 响应时间 = 至少需要 80 个并发 worker；每个 worker 占 60MB 内存 → 4.8GB，还没算连接数、文件句柄、上下文切换损耗。
-
ps aux | grep php-fpm查到几百个 sleeping 状态的进程，基本就是 IO 阻塞的铁证 - FPM 的
pm.max_children设太高，系统 load 会飙升，netstat -an | grep :9501 | wc -l可能远低于预期连接数——因为新请求进不来 - MySQL 的
Threads_connected接近max_connections，但Threads_running很低，说明连接被占着不动，不是 DB 慢，是 PHP 没释放
Hyperf 启动后 QPS 还上不去？先查这三件事
Hyperf 默认启动是协程模式，但很多团队没改配置或写了阻塞代码，结果跑成“伪协程”——看着是 Swoole 进程，实际还是串行等。
- 确认
config/autoload/server.php中'type' => Hyperf\Server\CoroutineServer::class，不是Swoole\HTTP\Server或默认异步风格 - 检查是否误用了
sleep()、file_get_contents()、curl_exec()等阻塞函数；协程里必须用Co::sleep()、Hyperf\HttpClient\Pool\ClientFactory、Db::select()（PDO 已被 Runtime Hook） - 运行
php bin/hyperf.php server:info，看输出里是否有enable_coroutine => true和hook_flags => SWOOLE_HOOK_ALL，缺一不可
连接池配多大才不拖后腿？
DB/Redis 连接池不是越大越好。设太大，Swoole 会创建过多 socket，触发 Too many open files；设太小，协程排队等连接，QPS 直接掉一半。
立即学习“PHP免费学习笔记（深入）”；
- MySQL 连接池：一般按
worker_num × 2 ~ 4设置pool.max_connections，比如worker_num = 8，max_connections = 24是安全起点 - Redis 连接池：如果只做缓存读写，
max_connections = 16够用；若混用 pub/sub 或 pipeline，建议拉到32 - 关键点：
pool.min_connections必须 > 0（如设为4），避免冷启动时每次都要新建连接，首屏延迟明显升高
报表/导出类任务别在 HTTP 请求里干
一个 Excel 渲染要 3 秒，放 Controller 里直接堵死整个 worker —— 协程调度器没法切走，其他请求全卡住。
- 必须扔进异步队列：
ReportRenderJob继承Hyperf\AsyncQueue\Job，用async-queue消费 - 消费进程数
processes和每进程并发协程数concurrent.limit要分开调：前者决定 CPU 核心利用率，后者决定单进程能并发多少 IO；推荐processes = 2+concurrent.limit = 10起步 - 切记加超时：
handle_timeout => 60，否则一个死循环任务会让整个消费者进程 hang 住
真正卡住 QPS 的，往往不是框架选型，而是某处 file_get_contents() 没换成协程客户端，或是 Redis 连接池 max 设成 100 却没调 ulimit -n，又或者报表任务塞进同步接口里还加了 ini_set('memory_limit', '2G') —— 这些细节不抠，万级 QPS 就是纸上谈兵。
