应优先增加 workers.count 配置值，因 frankenphp_busy_threads 长期偏低且 queue_depth 持续大于 0，表明线程池未充分利用；需结合 total_threads、内存占用及约束公式 num_threads × memory_limit 综合调整。
压测时 frankenphp_busy_threads 一直卡在低值，但 QPS 上不去
这说明 FrankenPHP 线程池没被充分利用，不是 CPU 不够，而是底层线程数成了瓶颈。常见于 Octane 启动时设了 --workers=8，但 workers.count 只配了 4——Octane 想拉 8 个 worker，FrankenPHP 却只肯给 4 个线程，剩下 4 个一直排队等资源。
- 先确认当前线程总数：
curl http://localhost:2019/metrics | grep frankenphp_total_threads - 再看忙时占比：
curl http://localhost:2019/metrics | grep frankenphp_busy_threads - 如果
frankenphp_busy_threads长期 ≤frankenphp_total_threads × 0.5，且frankenphp_queue_depth持续 > 0，优先加workers.count - 不要盲目翻倍：4 核机器从 4→8 有效，但从 8→16 往往 QPS 不升反降，因内存竞争加剧、GC 频率上升
wrk 显示 99% 延迟暴涨，但平均延迟变化不大
这是典型的线程过载信号。单个请求卡在队列里等线程，导致长尾延迟跳变，而平均值被大量快响应“拉低”。此时加线程数能直接缓解，但必须同步检查内存是否兜得住。
- 用
watch -n 1 'ps aux --sort=-%mem | head -5'观察 frankenphp-worker 进程内存占用是否逼近memory_limit - 验证约束公式：
num_threads × memory_limit ，例如 12 线程 × 256M = 3G，服务器只剩 2.5G 可用内存，就必然触发 OOM 杀进程 - 若内存吃紧，宁可把
num_threads从 12 降到 8，同时把memory_limit从 256M 提到 384M，比硬撑 12 线程更稳 - 压测中出现
Allowed memory size exhausted错误，说明线程数和 memory_limit 的乘积已越界，必须调低任一参数
调完 workers.count 后 wrk QPS 反而下降
大概率是 OPcache 或框架缓存失效了。FrankenPHP 每新增一个线程，就等于多一个独立的 PHP 运行时实例，每个实例的 OPcache 是隔离的。线程数翻倍后，若没预热或配置不当，会导致大量请求命中 cold cache，初始化开销集中爆发。
- 压测前必须执行：
frankenphp php-cli -r "opcache_reset();"，清空所有线程的 OPcache - 检查
opcache.validate_timestamps：设为0（生产环境必需），否则每次请求都校验文件时间戳，线程越多，IO 压力越大 - 确认
opcache.max_accelerated_files足够大（建议 ≥ 20000），否则新线程加载类时频繁触发哈希表淘汰 - 用
curl http://localhost/frankenphp/phpinfo查opcache.hits，压测中应稳定增长；若opcache.misses持续跳升，说明缓存没复用起来
怎么知道线程数调对了，而不是靠猜
没有银弹，但有两个硬指标比 QPS 更可靠：一是 frankenphp_busy_threads / frankenphp_total_threads 的比值稳定在 0.6–0.8 区间，二是 wrk 的 99% 延迟 ≤ 优化前的 70%。前者说明线程池既没闲置也没过载，后者证明长尾抖动真正被压下去了。
- 别信单次
wrk结果：必须连续三次压测，每次间隔 30 秒，取 99% 延迟的中位数 - 观察日志里
Worker #X restarted after max_requests是否规律出现——如果每 2 分钟固定重启一次，说明max_requests和线程数配合得当；如果秒级重启，就是内存或配置崩了 - 最易被忽略的是 Caddy 的 HTTP/3 开关：开启 HTTP/3 后，同一连接能并发更多请求，线程利用率会自然上升；压测时务必保持该开关状态一致，否则对比无效
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
