企业官网建设流程全解析

如何选择正确的并发数 -c：利特尔法则在Hey负载测试中的实际应用

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

hey 是一款轻量级 HTTP 负载测试工具（ApacheBenchab的现代替代品），其核心参数并发数-c却是最容易配错的一个：设小了压不满服务器，设大了会测出"假瓶颈"。本文用一句话就能讲清的利特尔法则（Little's Law），手把手教你 3 步算出并验证合理的并发数，让每次负载测试的结果都可信。

为什么并发数这么重要？

在 hey 的 hey.go 中，-n指定总请求数、-c指定并发 worker 数（默认 50 个 worker 跑 200 次请求，见 hey.go）。程序会启动 C 个 worker 轮流发请求，每个 worker 承担 N/C 次（requester/requester.go）：

• 并发太低：服务器根本没吃饱，测出的 QPS 不代表真实性能；
• 并发太高：请求在服务端排队，响应时间被排队时间"污染"，你会误以为系统很弱。

所以，-c不是"越大越好"，而是要按目标 QPS 反推。这就是利特尔法则的登场时机。

利特尔法则一句话回顾：C = 目标QPS × 平均响应时间

📐并发数 = 吞吐量 × 平均响应时间（即 L = λW）。

举个例子：

也就是说，若想让接口稳定承载 500 QPS，而单请求平均耗时 0.2 秒，那么系统里"同时在飞"的请求就是 100 个——这正是 hey 应该设置的-c 100。反过来，测试结束后也可以用实测QPS × 平均耗时去核对并发是否被充分利用（hey 的 RPS 与 Average 统计见 requester/report.go）。

3 步选对 Hey 并发数（完整操作清单）

第 1 步：低并发测基线延迟

先用温和的并发拿一个"不排队"的基线响应时间：

hey -n 200 -c 10 https://your-api.com/health

记下输出中的 Average（平均值）与 Latency distribution（延迟分布，见 requester/print.go）。

第 2 步：用利特尔法则反推 -c

确定业务目标 QPS 后直接套公式：-c = 目标QPS × 基线平均耗时(秒)。

💡 没有明确目标 QPS 时，可以用"压出拐点"法：从 10、50、100、200……逐步加大-c，观察 QPS 是否线性增长；一旦 QPS 不再涨而延迟持续恶化，上一档就是合理并发。

第 3 步：用 -q 限速验证（压到精确 QPS）

hey 的-q是每个 worker的 QPS 上限（requester/requester.go 中用 ticker 节流），总 QPS =-q × -c。要精确压 500 QPS，可以这样：

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

注意：是100 × 5 = 500，很多人误把-q当成总 QPS，这是最常见的坑 ⚠️。

如何判断并发数"选对了"？

跑完后对照 hey 的 Summary 报告（模板见 requester/print.go）：

• ✅Requests/sec 接近目标值：说明并发设置合理，利特尔法则成立；
• ⚠️P99 远高于 P50：并发过高导致排队，应下调-c或改用-q限速；
• ⚠️QPS 明显低于预期：可能瓶颈在压测机本身，可用-cpus控制 CPU 核心数，或-disable-keepalive排除连接复用带来的偏差。

常见错误与最佳实践

其他实用细节：-t控制单请求超时（默认 20s）、-H可重复添加自定义请求头、-h2开启 HTTP/2，完整参数说明见 README.md 与 Makefile、Dockerfile 中的构建配置。

小结

记住这条黄金公式即可告别"猜并发"：

C = 目标 QPS × 平均响应时间（秒）

先用低并发测基线 → 利特尔法则反推-c→ 用-q限速验证，三步走通后，hey 输出的 QPS、直方图与延迟分布才能真正代表你的系统能扛多少量。下次做 HTTP 负载测试时，不妨就把这 3 步当成标准检查清单。

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