单机 Hyperf 应用压测必须基于完整 HTTP 生命周期，启用协程调度、连接池与 ORM；禁用直连数据库、mock 和调试模式；JMeter 需命令行运行并配合理想资源；须结合 hyperf/metric 交叉验证协程、DB/Redis 连接池等核心指标。
单机部署的 Hyperf 应用上线前，压力测试与性能调优必须紧扣其协程本质——不能只看 QPS 数字，而要验证协程调度、连接池复用、中间件链路、ORM 封装等关键环节是否被真实触发。绕过 HTTP 层直连数据库或缓存，测出的数据毫无生产参考价值。
压测对象必须是完整 HTTP 请求生命周期
接口需走标准路由、中间件、协程上下文、DB 连接池和 ORM，禁用 Db::raw()、PDO 原生句柄或 mock 数据源：
- 定义最小真实接口，例如 GET /api/user/{id}，内部调用
UserModel::find($id)或Db::table('users')->where('id', $id)->first() - 关闭调试模式：
'debug' => false，避免 var_dump、调试日志、异常堆栈等额外开销 - 若含写操作，确保事务边界清晰（如使用
@Transactional），避免长事务阻塞协程池
JMeter 执行必须命令行 + 合理资源配比
GUI 模式会严重污染结果；高并发下 JVM 自身 GC 和 UI 线程会拖慢压测线程，导致 RT 虚高、TPS 虚低：
- 启动命令固定为：
jmeter -n -t test.jmx -l result.jtl -e -o report/ - 提前修改
jmeter.sh或jmeter.bat中的堆内存配置，例如：HEAP="-Xms2g -Xmx2g" - 线程组推荐使用「Concurrency Thread Group」插件，比原生线程组更稳定维持目标并发数
- Ramp-Up 时间不设为 0；日常流量建议设为 300 秒，秒杀类场景可设为 1–5 秒
必须结合 hyperf/metric 做指标交叉验证
仅看 JMeter 的 Aggregate Report 是盲人摸象。真实瓶颈常藏在框架层而非业务 SQL：
- 启用
hyperf/metric并配置'use_standalone_process' => true，避免监控逻辑干扰主协程调度 - 重点关注指标：协程创建总数、当前活跃协程数、DB 连接池 wait_time、Redis 连接池 busy_rate、HTTP 请求错误率与 P95/P99 延迟突变点
- 典型现象对照：
– P95 响应时间陡升但错误率为 0 → 协程池耗尽，新请求排队
– 直连 MySQL 压出 8000 QPS，而接口仅 1200 QPS 且 CPU 平稳 → max_connections 或 max_coroutine 配置不足
– Communications link failure 频发但接口正常 → DB 连接复用策略或超时参数不一致
核心配置项快速检查清单
上线前确认以下关键参数已按单机资源合理设置（以 4 核 8G 为例）：
-
swoole.max_coroutine = 3000（默认 3000，勿盲目调大，协程过多反增调度开销） -
db.pool.min_connections = 10，max_connections = 100（配合 MySQLmax_connections总量预留） -
redis.pool.max_connections = 200，wait_timeout = 0.1（避免等待过久阻塞协程） -
http_server.settings.worker_num = 4（通常设为 CPU 核心数） -
http_server.settings.task_worker_num = 4（异步任务如日志、邮件投递等）
