FrankenPHP高并发时CPU不高但响应很慢怎么排查-php教程-PHP中文网

frankenphp高并发响应慢的主因不是cpu不足，而是线程池过载、请求排队、i/o阻塞或下游依赖（如数据库连接耗尽、n+1查询）导致；需监控frankenphp_queue_depth和threads_busy率，并检查opcache配置与curl时序分段定位瓶颈。

frankenphp高并发时cpu不高但响应很慢怎么排查

不是CPU不够，是请求在排队或卡在别的地方——FrankenPHP高并发下响应变慢但CPU利用率低，90%的情况跟CPU无关，而是线程池、队列、I/O或下游依赖出了问题。

看 `frankenphp_queue_depth` 和线程池 busy 率

FrankenPHP 的核心瓶颈不在 CPU 占用率，而在 PHP 线程池的调度能力。即使 CPU 空闲，如果所有线程都在处理长耗时请求（比如没设超时的 cURL、慢 SQL、阻塞文件读写），新请求就会堆积在队列里。

访问 /metrics 端点（需 Caddy 启用 prometheus 指令），查 frankenphp_queue_depth：持续 > 0 就说明请求进不来，线程已满
同时看 frankenphp_threads_busy / frankenphp_threads_total 比值：长期 > 0.8 表示线程池严重过载，不是加核能解决的
别只盯 top 里的 CPU%，htop -p $(pgrep -f frankenphp) 才能看到每个线程是否处于 S（sleep）或 R（running）状态——大量 S 状态 + 高队列深度 = I/O 或外部依赖卡住

检查数据库连接池与 N+1 查询

Symfony/Laravel 在 FrankenPHP worker 模式下复用 Doctrine 连接，但默认不启用持久化，每请求新建连接又不显式释放，很快打满 MySQL 的 max_connections。此时请求会卡在“等待数据库连接”，CPU 几乎不涨，但响应时间飙升。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

执行 show status like 'Threads_connected';，对比 MySQL 的 max_connections 值，接近即为瓶颈
确认 Symfony 中 doctrine.dbal.connections.default.options 已设 pdo::ATTR_PERSISTENT: true
用 EXPLAIN 检查高频接口的 SQL，特别警惕 type: ALL 或 key: NULL；N+1 查询不会触发慢日志（单条快，合起来慢），必须在 PHP 层统计 PDO::query() 调用次数

抓 `curl -w` 时序拆解真实耗时位置

别靠肉眼刷页面猜，“慢”可能发生在 DNS、TLS、FPM 排队或 PHP 执行任意一层。用 curl 直连本地 FrankenPHP（绕过反向代理），把耗时分段打出来：

curl -s -o /dev/null -w \
'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
http://127.0.0.1:8080/api/test

如果 ttfb - tls（服务端处理时间）显著拉长，但 curl 进程本身 CPU 很低 → 问题在 FrankenPHP 线程池或下游
如果 connect 或 tls 高 → 检查 TLS 证书链、OCSP Stapling 或系统熵池（cat /proc/sys/kernel/random/entropy_avail）
如果 total - ttfb（内容传输时间）高 → 可能是大响应体未压缩，或输出缓冲未 flush

验证 OPcache 是否真生效且没被踢穿

FrankenPHP 常驻进程下，OPcache 是命脉。但配置错位会导致每次请求都重编译：比如 opcache.validate_timestamps = 1（开发模式残留）、opcache.max_accelerated_files 太小（Composer 自动加载文件多时极易击穿）。

写个临时脚本调 opcache_get_status()，重点看 num_cached_scripts：上线后应稳定在数百/数千，而不是长期
memory_usage.used_memory 接近 opcache.memory_consumption → 缓存池太小，频繁淘汰，等价于没开
检查 opcache.restrict_api 是否误配成 /public，导致指标接口本身被限制无法读状态

最常被忽略的是：FrankenPHP 的线程池大小和应用实际负载不匹配。8 核机器默认启 16 线程，但如果每个请求平均占 64MB 内存，16 × 64MB = 1GB，而服务器只有 2GB 可用内存，那第 17 个请求进来就直接 OOM —— 此时 top 看不到 CPU 高，只看到进程被 kill，然后重启，循环卡顿。