FrankenPHP怎么应对请求量突然增加-php教程-PHP中文网

frankenphp突发流量调优核心是防阻塞、防堆积、防雪崩：需按available_memory / memory_limit显式设num_threads，监控frankenphp_queue_depth>0和threads_busy率>0.8及时干预，配合opcache合理配置与泄漏点治理。

frankenphp怎么应对请求量突然增加

FrankenPHP 面对突发流量，核心不是“加资源”，而是防止线程池被阻塞、队列无限堆积、下游依赖雪崩——它本身不缺并发能力，缺的是请求不卡在 I/O 或外部服务上。

默认线程数是 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），优先保响应不排队

这个指标来自 /metrics 端点，代表请求已进入 FrankenPHP 但还没分配到 PHP 线程。持续大于 0，说明所有线程都在忙，新请求只能干等——此时 CPU 可能很低，但 TTFB 已经飙升。

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

下载

用 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 查询或开持久连接

Worker 模式下，OPcache 是性能命脉。但生产环境若设 opcache.validate_timestamps=0，部署新代码后请求会执行旧逻辑；设为 1 又可能因频繁 stat 拖慢响应。

线上必须设 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