FrankenPHP大流量下采用PHP线程池模型，调优核心是workers.count（即持久化PHP线程数）与max_requests：workers.count应按可用内存×0.8÷单线程平均RSS计算，推荐CPU核数×1.5～2.5起步；max_requests设500～2000防内存累积；需监控queue_depth与busy_threads，优先排查慢SQL和阻塞IO而非盲目增线程。
FrankenPHP 在大流量场景下不叫“worker 进程”，而是使用 **PHP 线程池（PHP threads）** 模型，每个线程长期驻留、复用执行环境，没有传统 PHP-FPM 的进程 fork 开销。所以调优重点不是“设多少 worker 进程”，而是配置 threads 数量 和 每个线程处理请求的上限。
threads.count 是核心参数，不是 CPU 核数简单倍数
在 /etc/frankenphp/frankenphp.yaml 中，关键配置是：
-
workers.count：实际指 PHP 线程总数（文档中称 workers，但底层是 goroutine 绑定的持久化 PHP 线程） - 推荐初始值设为 CPU 物理核心数 × 1.5～2.5，而非 ×2 硬套。例如 8 核服务器，可从 12 或 16 起步
- 超过 24 后提升收益明显放缓，需配合内存监控判断是否真能撑住
内存比 CPU 更快成为瓶颈
每个 FrankenPHP 线程常驻内存约 40–70 MB，取决于加载扩展（如 opcache、pdo_mysql）、应用代码体积和日志级别。不能按空载估算。
- 实测单线程 RSS 建议用
ps aux --sort=-%mem | grep frankenphp抓稳定运行中的多个线程取平均值 - 安全上线程数 ≈ （可用内存 MB × 0.8） ÷ 单线程平均 RSS（MB）
- 例：16GB 内存服务器，扣除系统和其他服务后剩 12GB 可用 → 12288 MB × 0.8 ÷ 52 MB ≈ 189，那就别设
workers.count > 185
max_requests 防止长时运行导致内存缓慢增长
即使线程持久化，某些扩展或未释放资源仍可能造成轻微内存累积。该参数强制线程在处理指定请求数后自动重启：
立即学习“PHP免费学习笔记（深入）”；
- 生产环境建议设为 500～2000，高稳定性要求选 1000，高动态代码更新频率可设低些（如 500）
- 不要设为 0（永不重启），也无需设过高（如 10000），起不到额外收益，反而延迟潜在泄漏暴露
- 搭配 Prometheus 监控
frankenphp_worker_restarts_total指标，若重启过于频繁（如每分钟多次），说明存在内存泄漏需排查
突发流量下靠队列深度 + 平滑扩容更有效
FrankenPHP 支持请求排队，frankenphp_queue_depth 是关键观测指标：
- 当
queue_depth持续 > 10 且busy_threads接近total_threads，说明当前线程数已饱和 - 比起盲目加线程，优先检查是否有慢 SQL、阻塞 IO（如未用协程的 Redis/mysqli 调用）
- 若确认是纯计算或协程友好型业务，再逐步上调
workers.count，每次+2～4，压测验证
