vegeta 支持原生阶梯式加压，通过分阶段提升 RPS（如50→100→200）并监控 queue_length、99%延迟和 OOM 重启来精准暴露 FrankenPHP 瓶颈；wrk 因连接复用不可控、无速率阶梯能力且冷启动干扰大而不适用。
vegeta attack 怎么做阶梯式加压
FrankenPHP 的 worker 生命周期和连接复用特性，让传统线性加压（如 wrk -c100）容易掩盖排队抖动。真正暴露瓶颈的方式是分阶段提升并发量，观察队列长度、99%延迟和 OOM 重启是否突增。
vegeta 是目前唯一支持原生阶梯加压的 CLI 工具，它能按秒级节奏递增请求速率，且保留 HTTP/2 和响应体校验能力：
-
vegeta attack -targets=targets.txt -rate=50 -duration=10s -http2：起始 50 RPS，持续 10 秒 -
vegeta attack -targets=targets.txt -rate=100 -duration=10s -http2：升至 100 RPS，再 10 秒 -
vegeta attack -targets=targets.txt -rate=200 -duration=10s -http2：继续翻倍，观察是否出现context deadline exceeded
不要用 -rate=0（无限速率），FrankenPHP 的 worker 队列无背压保护，瞬间打满会直接卡死状态端点。每次加压后必须检查 /fpm-status?json 返回里的 queue_length —— 超过 5 就说明 PHP worker 已开始排队，不是网络问题。
为什么 wrk 不适合逐步加压
wrk 的 -c 参数控制的是“维持的并发连接数”，不是“每秒请求数”。它默认复用连接，但 FrankenPHP 在 HTTP/2 下每个连接可承载多路请求，-c100 实际可能产生远超 100 的瞬时压力，且无法控制 ramp-up 时间。
立即学习“PHP免费学习笔记（深入）”；
更关键的是，wrk 没有内置的速率阶梯指令，强行用 shell 循环调用（如 for r in 50 100 200; do wrk -t4 -c$r ...; done）会导致每次启动都触发冷启动、OPcache 重载、worker reload，测的不是负载能力，而是初始化抖动。
常见错误现象：curl -s http://localhost:8000/fpm-status?json | jq '.active_workers' 显示 worker 数稳定在 8，但 queue_length 却飙升到 50+ —— 这说明请求已堆积在 Go 层调度队列，PHP worker 根本没来得及处理。
加压过程中必须监控的三个指标
逐步加压不是为了刷高 QPS 数字，而是定位拐点。以下三项必须在每次加压段结束后立刻采集：
- 用
curl -s http://localhost:8000/fpm-status?json查queue_length和active_workers：若前者增长而后者不变，说明 worker 已饱和 - 用
opcache_get_status()['opcache_statistics']['oom_restarts']检查是否发生内存溢出重启（需在 PHP 脚本中临时加var_dump(opcache_get_status());输出） - 看系统级
cat /sys/fs/cgroup/memory/memory.usage_in_bytes（容器内）或ps aux --sort=-%mem | head -5（宿主机），确认 RSS 是否逼近memory_limit设置值
FrankenPHP 的弹性扩容（max_threads）只对 CPU 密集型请求有效；一旦进入 I/O 等待（比如 MySQL 查询慢、Redis 阻塞），再多线程也救不了队列堆积——这时候该优化的是 SQL 或加缓存，不是调 num_threads。
加压脚本里最容易漏掉的 reset 步骤
每次加压段切换前，必须重置运行时状态，否则上一轮的 OPcache 命中、连接池复用、日志缓冲会污染下一轮数据：
- 清空 OPcache：
frankenphp php-cli -r "opcache_reset();" - 重启 worker（如果用了
worker.php）：pkill -f worker.php && frankenphp run，避免 terminate() 积压未执行 - 禁用 Laravel/Symfony 的 debugbar、clockwork 等调试中间件，它们会在每次响应头注入额外 payload，干扰延迟测量
最常被忽略的一点：FrankenPHP 的 --max-requests 默认是 0（永不重启），压测中若不手动设为 1000，worker 可能因内存缓慢泄漏，在第三轮加压时突然崩溃 —— 表现为 queue_length 归零后长时间无响应，而不是报错。
