hyperf上线前压测必须走http接口而非直连mysql，否则qps、rt、错误率失真，无法反映协程调度、连接池及中间件真实瓶颈；需确保完整请求生命周期、禁用非协程调用、关闭调试模式；jmeter须命令行运行、合理配置jvm与线程组，并用hyperf/metric指标交叉验证。
Hyperf 上线前压测必须走 HTTP 接口，不能直连 MySQL；否则 QPS、RT、错误率全部失真，根本看不出协程调度、连接池、中间件的真实瓶颈。
为什么不能用 JMeter 直连 MySQL 压测 Hyperf 服务
直连 MySQL 看似省事，实则绕过了 Hyperf 所有关键运行环节：路由匹配、中间件（如鉴权、日志）、协程上下文注入、Db 连接池复用、ORM 封装逻辑。常见误导现象包括：
-
Communications link failure在直连时高频报错，但/api/user/{id}接口完全正常——问题大概率出在 JMeter 连接复用策略或超时配置，而非 DB 本身 - 直连压出 8000 QPS，HTTP 接口仅 1200 QPS，且 CPU/内存平稳——说明
max_connections或max_coroutine触发了排队，不是 DB 慢 - P95 响应时间陡升但错误率为 0——典型协程资源耗尽，新请求在队列中等待，不是网络或 DB 卡顿
Hyperf 接口压测必须满足的三个真实条件
压测对象得是完整生命周期的 HTTP 请求，否则指标无业务意义。需确保：
- 接口路径真实存在且经过完整流程，例如
GET /api/user/{id}，内部调用UserModel::find($id)或Db::table('users')->where('id', $id)->first() - 禁用
Db::raw()、裸PDO或file_get_contents等非协程调用，否则会退化为同步阻塞 - 关闭调试模式：
'debug' => false，避免var_dump、调试日志序列化等额外开销干扰 RT 和吞吐
JMeter 命令行执行与并发控制要点
GUI 模式会污染结果，JMeter 自身 Swing 线程和 GC 开销会直接拉高 RT、压低 TPS。正确做法是：
- 使用命令行非 GUI 模式：
jmeter -n -t test.jmx -l result.jtl -e -o report/ - 提前调大 JVM 堆内存，例如修改
HEAP="-Xms2g -Xmx2g"，否则高并发下 GC 反向拖慢压测线程 - 线程组优先选
Concurrency Thread Group（需插件），比原生线程组更能稳定维持目标并发数 -
Ramp-Up Period别设为 0；日常模拟建议设为 300 秒，给系统缓冲时间；秒杀类可设为 1
必须用 hyperf/metric 对齐验证，不能只信 JMeter 报告
Aggregate Report 是盲人摸象。Hyperf 运行时指标才是瓶颈定位依据：
- 启用
hyperf/metric并配置'use_standalone_process' => true，避免监控逻辑抢占业务协程资源 - 重点对齐：协程创建总数、当前活跃协程数、DB 连接池空闲/使用数、HTTP Server 请求队列长度
- 若 JMeter 显示 QPS 下降但
coroutine_active_num持续接近max_coroutine，说明协程已成瓶颈，不是 DB 或网络问题
真正难的不是跑出数字，而是让 JMeter 的 result.jtl 和 hyperf/metric 暴露的指标能互相解释得通——比如 P99 RT 跳升时，server.request_queue_length 是否同步堆积，db.pool.idle_connections 是否归零。这些交叉点，才是上线前最该盯住的地方。
