FrankenPHP突发流量调优核心是防阻塞、防堆积、防雪崩：需按available_memory / memory_limit显式设num_threads，监控frankenphp_queue_depth>0和threads_busy率>0.8及时干预，配合OPcache合理配置与泄漏点治理。
FrankenPHP 面对突发流量，核心不是“加资源”，而是防止线程池被阻塞、队列无限堆积、下游依赖雪崩——它本身不缺并发能力，缺的是请求不卡在 I/O 或外部服务上。
怎么调 num_threads 和 worker 数量才不翻车
默认线程数是 CPU 核心 × 2，但这个值对突发流量几乎无效。真正起作用的是：线程数 × 单请求内存上限必须小于可用内存，否则一压就 OOM。
- 先查服务器真实空闲内存：
free -h看available列，别信total - used - 确认 PHP 的
memory_limit（比如256M），算出理论最大线程数：available_memory / memory_limit，向下取整 - 在 Caddyfile 中显式设
php_server { num_threads 12 }或frankenphp { worker { num 8 } }，别依赖默认值 - 如果应用大量调用
curl、file_get_contents或数据库查询，线程数宁可保守（比如 8～12），优先保响应不排队
为什么 frankenphp_queue_depth 持续 > 0 就得立刻干预
这个指标来自 /metrics 端点，代表请求已进入 FrankenPHP 但还没分配到 PHP 线程。持续大于 0，说明所有线程都在忙，新请求只能干等——此时 CPU 可能很低，但 TTFB 已经飙升。
- 用
curl http://127.0.0.1:2019/metrics 2>/dev/null | grep frankenphp_queue_depth实时看 - 同时查
frankenphp_threads_busy / frankenphp_threads_total比值，长期 > 0.8 就说明线程池过载，不是加核能解决的 - 别只盯着
top，用htop -p $(pgrep -f frankenphp)看线程状态：如果一堆是S（sleep），说明卡在 I/O 或下游，不是 CPU 问题 - 队列深度突增时，立刻检查数据库连接数：
show status like 'Threads_connected';，接近max_connections就要砍 N+1 查询或开持久连接
OPcache 和 opcache.validate_timestamps 怎么配合扛住瞬时高峰
Worker 模式下，OPcache 是性能命脉。但生产环境若设 opcache.validate_timestamps=0，部署新代码后请求会执行旧逻辑；设为 1 又可能因频繁 stat 拖慢响应。
立即学习“PHP免费学习笔记（深入）”；
- 线上必须设
opcache.validate_timestamps=1，并配opcache.revalidate_freq=180（3 分钟校验一次） - 发布时，不要只 reload Caddy，要主动触发
opcache_reset()（比如 curl 一个健康检查端点，里面调这个函数） - 验证是否生效：
opcache_get_status()['opcache_statistics']['num_cached_scripts']应该稳定在高位（比如 > 5000），oom_count必须为 0 - 如果
opcache.memory_consumption不够，脚本缓存会频繁淘汰，导致反复编译，TTFB 波动剧烈
突发流量下最容易被忽略的三个泄漏点
这些不会报错，但会随时间推移让同一台机器越来越慢，直到某次流量尖峰直接卡死。
-
Monolog\Handler\StreamHandler在常驻进程中重复打开日志文件，快速耗尽ulimit -n——必须换RotatingFileHandler并设max_files: 7 - Symfony 的
RequestStack或 Doctrine 连接未重置，导致后续请求读到上一个请求的残留数据 —— 在public/index.php开头清空$_SERVER和$_REQUEST - Caddy 日志轮转没用
copytruncate，日志文件 inode 耗尽后写入阻塞，整个 HTTP 层变慢 —— logrotate 配置里必须含copytruncate和create
突发流量不是测出来的，是压出来的；而压出来的问题，90% 都藏在线程是否真在干活、下游是否还活着、以及资源是否悄悄泄漏这三个地方。
