ab或hey发起并发请求需禁用Keep-Alive以暴露FrankenPHP的串行瓶颈：ab用-k false，hey默认短连接更优；关键指标frankenphp_queue_depth反映请求是否堵在调度队列，配合frankenphp_busy_threads比值及frankenphp_worker_queue_depth标签可精准定位线程争抢或Worker阻塞问题。
用 ab 或 hey 发起并发请求，但必须绕过默认的 Keep-Alive
FrankenPHP 的“串状态”问题（比如线程被意外独占、Worker 未及时释放、请求排队不均）在单请求下完全不可见。真实暴露往往发生在短连接高并发场景——而 ab 默认启用 HTTP/1.1 Keep-Alive，会复用连接，掩盖线程争抢和排队行为。
正确做法是强制关闭长连接：
-
ab -n 100 -c 20 -k false http://localhost/health.php（-k false禁用 Keep-Alive） - 更推荐
hey：它默认就是短连接，且支持超时控制：hey -n 100 -c 20 -timeout 5s http://localhost/health.php - 避免用浏览器 F5 刷新测——它带缓存、预加载、连接复用，结果完全失真
frankenphp_queue_depth 是判断是否真“串”的第一指标
你看到响应变慢或 503，并不等于线程真的卡死；可能只是请求在进 PHP 前就堵在 FrankenPHP 的调度队列里了。这个队列深度由 frankenphp_queue_depth 指标实时反映，它只在 Caddy metrics 启用后存在。
验证步骤：
立即学习“PHP免费学习笔记（深入）”；
- 先确保 Caddyfile 有
metrics全局指令（不是仅admin） - 启动后 curl
http://localhost:2019/metrics | grep frankenphp_queue_depth - 在压测中持续观察该值：若稳定 > 0 且随并发线性增长，说明请求还没进线程池就被拦住了——这时问题不在 PHP 代码，而在
num_threads配置过小或max_wait_time过短
加 worker 标签才能定位具体脚本的排队行为
普通 PHP 请求的排队看 frankenphp_queue_depth 就够了，但如果你开了 Worker 模式（比如 php_server worker /path/to/worker.php），那每个 Worker 脚本会有独立排队指标：frankenphp_worker_queue_depth{worker="/path/to/worker.php"}。
这意味着：
- 不同 Worker 脚本之间排队互不影响，不能只看全局队列
- 若某 Worker 的
queue_depth持续 > 0，但frankenphp_busy_threads很低，大概率是该 Worker 内部阻塞（比如死循环、同步 I/O、未设超时的 cURL） - 用
curl http://localhost:2019/metrics | grep 'worker_queue_depth'可直接确认标签值是否匹配你配置的路径
别忽略 frankenphp_busy_threads 和 frankenphp_total_threads 的比值
线程池是否真正打满，不能只看 busy_threads 绝对值。例如你配了 num_threads 4，压测中 busy_threads 卡在 4 不动，而 queue_depth 持续上涨——这说明线程数确实是瓶颈，但要注意：
-
max_threads auto不会自动突破num_threads下限；它只在num_threads设为较小值（如 2）且启用了max_threads时才扩容 - 如果
busy_threads始终远低于total_threads（比如 4/8），却仍有排队，问题可能出在 PHP 层：某个请求执行太久（未设max_execution_time）、或 Worker 主动 sleep 未 yield - 临时验证可改
php_ini max_execution_time 2，再压测看busy_threads是否快速回落
真正难排查的是“伪串行”：线程没满、队列没积压、但响应时间抖动极大。这时候得盯 frankenphp_worker_duration_seconds_sum 分位数，以及检查是否混用了同步阻塞调用——FrankenPHP 的线程是共享的，一个 Worker 里 file_get_contents("http://slow-api") 会拖垮整个线程，而不是像 Swoole 那样协程隔离。
