Go语言如何做HTTP接口压力测试_Golang hey工具负载生成方法-Golang-PHP中文网

hey是go生态中轻量级命令行压测工具，支持http/https/http2/websocket，依托goroutine实现高并发，提供详尽响应时间分布、状态码统计及网络耗时分析；安装推荐直接下载预编译二进制而非go install，避免goproxy问题；核心参数-c控制并发worker数、-q限制单worker qps，二者协同决定真实压力；关键指标应关注p95/p99响应时间、非2xx状态码及dns/connect/processing分段耗时，以精准定位服务瓶颈。

go语言如何做http接口压力测试_golang hey工具负载生成方法

hey 是 Go 生态里最轻量、最贴近真实压测需求的命令行工具——它不依赖 GUI，不抽象配置，所有参数直击核心：并发数、请求数、QPS、超时、协议版本。你不需要写代码就能拿到接近生产环境的响应时间分布和错误归因。

怎么装 `hey` 才不会遇到 `command not found`

别用 go install github.com/rakyll/hey@latest 直接装，Go 1.21+ 默认启用 GOPROXY=direct 时容易拉不到模块（尤其国内网络），报 no matching versions 或卡在 resolve 阶段。

推荐做法是跳过 Go 模块安装，直接下载预编译二进制：

Linux：wget https://storage.googleapis.com/hey-releases/hey_linux_amd64 -O /usr/local/bin/hey && chmod +x /usr/local/bin/hey
macOS：curl -L https://storage.googleapis.com/hey-releases/hey_darwin_amd64 -o /usr/local/bin/hey && chmod +x /usr/local/bin/hey
Windows：下载 hey_windows_amd64.exe，重命名为 hey.exe，加到 %PATH%

验证是否生效：hey -h 能输出帮助即成功。注意：不要把二进制放在带空格或中文路径下，否则 hey -z 10s https://a.com 会静默失败。

`-c` 和 `-q` 到底控制什么？别混用导致 QPS 假高

-c 是并发 worker 数（即“同时发多少个请求”），-q 是每个 worker 每秒最多发几个请求。两者叠加才是真实压力源。

例如：hey -c 50 -q 10 https://api.example.com 表示启动 50 个 goroutine，每个每秒最多发 10 次，理论峰值 QPS = 50 × 10 = 500 —— 但实际受服务端吞吐、网络延迟、DNS 解析速度限制。

常见误用：

只设 -c 1000 不设 -q：瞬间打出上千连接，本机先扛不住（socket: too many open files）
设 -q 100 但 -c 1：只有一个 worker，根本打不出 100 QPS（最大就是 100/s，但波动极大）
目标是稳态压测（如验证能否扛住 300 QPS）：必须 -c ≥ -q，且 -c 建议设为 -q 的 2–5 倍，留出调度余量

真实建议值：-c 200 -q 50 比 -c 50 -q 200 更稳定，后者容易因单 worker 卡顿拖垮整体节奏。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

为什么 `-h2` 开启后响应时间突增甚至失败？

-h2 强制走 HTTP/2，但它要求服务端明确支持 ALPN 协商，且 TLS 握手必须成功。很多 Nginx/OpenResty 默认没开 HTTP/2，或证书链不全，此时 hey -h2 会 fallback 失败，卡在 tls: handshake failure 或直接 timeout。

判断是否真走 HTTP/2：

加 -v 参数看日志：hey -h2 -v https://api.example.com 2>&1 | grep "HTTP/2"
失败时典型错误：Get "https://...": remote error: tls: internal error 或 http2: server sent GOAWAY and closed the connection

安全做法：

先不加 -h2 跑通基础压测
确认服务端已启用 HTTP/2（curl -I --http2 https://api.example.com 返回 HTTP/2 200）
再加 -h2 并配 -t 30（延长 TLS 握手超时），避免个别慢握手拖垮全局

注意：-h2 会自动禁用 -disable-keepalive，因为 HTTP/2 依赖长连接，强行关会导致 panic。

`hey` 输出里哪些字段真正反映服务瓶颈？

别只盯着 “Requests/sec”（QPS）和 “Total time”。关键看三组分布数据：

Response time distribution：关注 95% 和 99% 分位耗时。如果 50% = 20ms 但 99% = 2s，说明存在慢查询或锁竞争，不是吞吐问题而是稳定性问题
Status code distribution：出现非 2xx 码时，立刻查服务端日志。特别警惕 429（限流）、503（上游不可用）、504（网关超时）——这些比 QPS 下降更早暴露架构缺陷
Network times breakdown：对比 DNS Lookup、Connect、Processing 耗时。若 DNS Lookup 占比 >30%，说明没配 DNS 缓存或解析慢；若 Connect 显著高于 Processing，可能是服务端连接池不足或 TCP backlog 溢出