企业官网建设流程全解析

Hey压测应该跑多久？-z与-n两种模式的实战决策指南

【免费下载链接】heyHTTP load generator, ApacheBench (ab) replacement项目地址: https://gitcode.com/GitHub_Trending/he/hey

做压测时，新手最常纠结的问题就是：压测到底该跑多久？答案藏在 Hey 这款轻量级HTTP 压测工具（ApacheBench 的现代替代）的两个参数里——-n（固定请求数）和-z（固定时长）。本文用一次清晰的决策流程，帮你在 30 秒内选对模式。

🚀 先认识 Hey：30 秒上手 HTTP 压测工具

Hey 是一个"小而美"的压测程序：向 Web 应用发送持续负载，并输出延迟分布、RPS、错误分布等完整统计。它支持 HTTP/2、限速、自定义请求头等能力，比老牌的ab更易用。

需要体验源码时，可直接克隆仓库：

git clone https://gitcode.com/GitHub_Trending/he/hey

完整参数说明见 README.md。

⚖️ 本质区别：-n 与 -z 到底差在哪？

一个关键细节：

同时指定-z和-n时，-n会被直接忽略。

源码中只要-z > 0，请求总数就被置为极大值，直到定时器到点才停止（见 hey.go 与 hey.go）。所以二选一，不要同时写。

📊 场景一：用 -n 模式，把"变量"锁死

当你想回答"这次改动让接口变快还是变慢了"时，用-n：

• 两次压测请求量相同，RPS 和延迟才有可比性；
• 跑完即停，适合频繁执行的回归测试；
• 注意约束：-n不能小于-c（并发数），否则会直接报错退出（hey.go）。

示例（来自 README.md）：

hey -n 1000 -c 100 https://your-api.com/health

💡建议：对比场景下至少跑-n 1000起步。Hey 的延迟分布会输出 P10 到 P99 各百分位（requester/report.go），样本太少时 P99 基本是"噪声"。

⏱️ 场景二：用 -z 模式，模拟真实流量窗口

当你想回答"系统能不能扛住持续 5 分钟的在线流量"时，用-z：

• 耗时固定，方便规划压测窗口和观察服务端监控曲线；
• 能暴露预热、连接池耗尽、缓存失效等只有持续压力才会出现的问题；
• 配合-q限速可以精确控制 QPS（如每 worker 每秒 10 次请求）：

hey -q 10 -c 5 -z 30s https://your-api.com/health

🎯 压测该跑多久？分场景决策表

经验法则：结论用于"对比"，就按请求数（-n）；结论用于"扛不扛得住"，就按时长（-z）。时长类压测至少 1 分钟起步，短于这个窗口很难看出趋势变化。

⚠️ 新手必知的 4 个细节

1. -z优先：指定-z后-n失效，写两者只会浪费记忆负担；
2. 并发约束：-n必须 ≥-c，默认并发是 50（hey.go）；
3. 超时保护：单次请求默认 20 秒超时（-t 20），慢接口注意调整，否则大量超时会污染统计；
4. 统计上限：报告最多收录 100 万个请求样本（requester/report.go），超长压测超出部分的样本不再进入百分位统计，总量以 RPS 为准。

✅ 一张清单收尾

• 想快速验证接口是否健康？→hey -n 200 <url>，默认参数就够
• 想对比两个版本谁更快？→ 用相同的-n（≥1000）各跑一遍
• 想知道真实流量下能扛多少？→hey -z 5m <url>，同时盯住服务端监控
• 想精确控速？→-z搭配-q，把 QPS 锁在目标值

记住：没有"标准时长"，只有"匹配目的的时长"——请求数对比用-n，时间窗口模拟用-z，选对之后，Hey 给出的 RPS、P95/P99 和错误分布，就是你决策的全部依据。

【免费下载链接】heyHTTP load generator, ApacheBench (ab) replacement项目地址: https://gitcode.com/GitHub_Trending/he/hey