压测 Hyperf 接口性能的 wrk 工具使用教程【性能测试】-php教程-PHP中文网

wrk压测hyperf接口前必须确认三件事：一是服务启用http server并监听0.0.0.0:9501且防火墙放行；二是server.php中worker_num≥cpu核数×2、max_connection≥wrk的-c值；三是禁用debugmiddleware等调试中间件及debug日志级别。

压测 hyperf 接口性能的 wrk 工具使用教程【性能测试】

wrk 压测 Hyperf 接口前必须确认的三件事

直接跑 wrk -t4 -c100 -d10s http://localhost:9501/health 很可能测不准，甚至压不出真实吞吐量。Hyperf 默认启用协程调度和连接池，但 wrk 的线程、连接、超时配置若与服务端不匹配，会掩盖瓶颈或触发假性超时。

确认 Hyperf 服务已启用 http server（非 Swoole CLI 模式），监听地址为 0.0.0.0:9501（默认）且未被防火墙拦截
检查 config/autoload/server.php 中 setting 是否设置了合理 worker_num（建议 ≥ CPU 核数 × 2）和 max_connection（建议 ≥ wrk 的 -c 总值）
确保未启用调试中间件（如 DebugMiddleware）或日志级别为 debug，否则 I/O 开销会严重干扰 QPS 结果

线程数（-t）和连接数（-c）怎么配才不翻车

Hyperf 是协程模型，不依赖多线程处理请求，所以 wrk 的 -t 不代表“并发用户数”，而是控制本地发起请求的并发能力上限；-c 才真正模拟客户端长连接数量。配错会导致 socket 耗尽、TIME_WAIT 爆满或 CPU 在 wrk 自身调度上打转。

-t 建议设为 CPU 物理核数（nproc 查看），最大不超过 2 × nproc；超过后线程上下文切换开销上升，Req/Sec 反而下降
-c 应 ≥ 预期并发请求数，但需小于服务端 max_connection 和系统 net.core.somaxconn；例如压测 2000 并发，可设 -c2000，但必须同步调大 Hyperf 的 max_connection 至 ≥ 2500
避免 -c 远大于 -t（如 -t2 -c2000）：单线程要维护 1000 个连接，容易因事件循环阻塞导致延迟毛刺

用 Lua 脚本发 POST/带 Token 的请求（hyperf-jwt 场景）

Hyperf 常用 hyperf/jwt 或 hyperf/auth 做鉴权，直接压测未授权接口会大量返回 401，测的不是业务性能而是鉴权链路。必须用 Lua 脚本动态注入 Authorization 头或构造 JSON body。

Hyperframes Creative

HyperFrames视频非动画创意指导，包括设计规范（frame.md/design.md）处理、配色、字体设计、旁白及节奏规划等。

下载

示例脚本 auth_post.lua：

wrk.method = "POST"
wrk.body   = '{"username":"test","password":"123456"}'
wrk.headers["Content-Type"] = "application/json"
wrk.headers["Authorization"] = "Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxLCJ1c2VybmFtZSI6InRlc3QiLCJleHAiOjE3MjI5NzYwMDB9.aBcDeFgHiJkLmNoPqRsTuVwXyZ"

执行命令：wrk -t4 -c200 -d10s -s auth_post.lua --latency http://localhost:9501/login

Token 必须是有效且未过期的，否则所有请求失败；建议提前用 Hyperf 的 JWTAuth 生成一批 token 存入数组，再用 math.random 轮询，避免单 token 被限流
不要在 init 函数里做网络请求（如调用登录接口取 token）：wrk 每个线程只运行一次 init，无法支撑高并发下的 token 刷新
若接口要求 form-data，Lua 脚本需手动拼接 boundary，不如改用 curl + ab 组合，wrk 对 multipart 支持弱

--latency 和 --timeout 的实际影响

--latency 不仅是“显示更多数字”，它强制 wrk 记录每个请求的完整生命周期（从 connect 到 recv body 完毕），开启后内存占用明显上升，10 万请求可能吃掉 200MB+；而 --timeout 默认仅 2s，Hyperf 若启用了慢日志或数据库慢查询，很容易把正常请求判为超时。

压测前务必加 --timeout 10s（尤其含 DB 查询或外部 HTTP 调用的接口），否则 Requests/sec 会被大量 Timeouts 拉低，误判为服务不可用
--latency 只在定位延迟分布问题时开启（如排查 99% 延迟突增），日常基准测试可省略以降低 wrk 自身开销
结果中 Latency Distribution 的 99% 值比平均延迟更有意义：Hyperf 协程切换快，但若某次 MySQL 查询卡住 500ms，它就会体现在 99% 分位里，这才是真实尾部延迟

Hyperf 的协程调度器对短平快请求极其友好，但 wrk 的连接复用机制和 Hyperf 的连接池配置稍有不匹配，就可能让测试结果偏离真实承载能力——重点不在“压得多”，而在“压得准”。