必须通过Hyperf HTTP接口压测而非直连MySQL，否则会绕过路由、中间件、协程调度、连接池及ORM等关键环节，导致QPS和响应时间无法反映真实业务性能；需结合hyperf/metric采集全链路指标进行交叉验证。
不能只用 JMeter 直连 MySQL 做压测，否则测出来的 QPS 和响应时间跟真实业务接口毫无关系——Hyperf 的路由、中间件、协程调度、DB 连接池、ORM 封装等全被绕过了。
为什么必须走 HTTP 接口压测，而不是直连数据库
直连 MySQL 的 JMeter 测试看似简单，但会掩盖所有框架层瓶颈。常见现象包括：
-
Communications link failure在直连时频繁报错，但 Hyperf 接口完全正常——说明问题出在连接复用策略或超时配置不一致，而非数据库本身 - 直连压出 8000 QPS，而通过
/api/user/{id}接口压测只有 1200 QPS，且 CPU 和内存都很平稳——大概率是max_connections设太小，或max_coroutine触发排队 - P95 响应时间突然跳升，错误率为 0——这通常意味着协程资源耗尽，新请求在等待可用协程，而不是 DB 慢或网络卡
Hyperf 接口准备：暴露一个带 DB 查询的真实路径
压测对象必须是完整生命周期的 HTTP 请求。推荐做法：
- 在控制器中写一个最小但真实的接口，例如：
GET /api/user/{id}，内部调用Db::table('users')->where('id', $id)->first()或UserModel::find($id) - 确保该接口经过中间件（如鉴权、日志）、路由匹配、协程上下文注入，不走
Db::raw()或裸 PDO - 禁用开发环境的调试信息输出（如
debug配置为false），避免额外序列化和日志 IO 干扰 - 若涉及写操作，需确认事务边界清晰，避免长事务拖慢整体吞吐
JMeter 执行必须用命令行非 GUI 模式
GUI 模式会严重污染结果，JMeter 自身的 Swing 线程和内存开销会直接拉高 RT、压低 TPS。正确方式是：
- 启动命令必须为：
jmeter -n -t test.jmx -l result.jtl -e -o report/ - 提前在
jmeter.bat或jmeter.sh中调大堆内存，例如修改HEAP="-Xms2g -Xmx2g"，否则高并发下 JVM GC 会反向拖慢压测线程 - 线程组使用「Concurrency Thread Group」（需插件），比原生线程组更能稳定维持目标并发数
- Ramp-Up Period 不要设为 0；秒杀类场景可设为 1，日常流量模拟建议设为 300 秒，让系统有缓冲时间
用 hyperf/metric 暴露指标，和 JMeter 结果交叉验证
只看 JMeter 的 Aggregate Report 是盲人摸象。必须把 Hyperf 运行时指标拉出来对齐分析：
- 启用
hyperf/metric并配置为独立进程：'use_standalone_process' => true，避免监控逻辑干扰业务协程 - 关键指标重点关注：
hyperf_http_server_requests_seconds_bucket（响应延迟分布）、hyperf_db_queries_total（SQL 执行次数）、swoole_server_coroutine_count（实时协程数） - 将
metric指标接入 Prometheus + Grafana，在压测期间同步观察：协程数是否打满、DB 查询是否陡增、HTTP 请求是否出现长尾 - 若发现
JMeter报告中 TPS 下降，但swoole_server_coroutine_count长期卡在max_coroutine上限，就该立刻调大配置项swoole.max_coroutine
真正卡住性能的，往往不是 SQL 本身，而是协程调度器没拿到足够资源、连接池满了没人释放、或者某段同步阻塞代码（比如未协程化的 file_get_contents）把整个 worker 拖住了。这些，只有走完整 HTTP 链路 + 框架指标联动，才能定位清楚。
