Hey压测概念速成课：新手必懂的并发、QPS、RPS、延迟与TTFB五大核心概念

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

Hey 是一款用 Go 编写的轻量级HTTP 压测工具（load generator），常被用作 ApacheBench（ab）的替代品。本文将用 5 分钟带你读懂压测报告里的五大核心概念：并发（Concurrency）、QPS、RPS、延迟（Latency）与 TTFB，让你拿到 hey 的输出报告后不再一脸茫然 🎯

先认识 Hey：它到底在压什么？

一句话概括：Hey 按你设定的并发度和请求量，向目标 Web 服务"灌入"流量，然后打印一份统计报告。

它的工作原理其实很简单：启动一批"worker（工人）"，每个 worker 循环向目标 URL 发请求，同时用httptrace精细记录每个请求在 DNS 解析、建连、写请求、等待响应、读响应各阶段花的时间，最后汇总成报告。入口逻辑在 hey.go 中完成参数解析，真正的压测引擎在 requester/requester.go。

一条命令就能跑起来（macOS 用户可通过包管理器brew install hey安装）：

hey -n 1000 -c 100 https://example.com

这条命令的意思是：用 100 个并发 worker，总共发 1000 个请求。看懂下面五个概念，你就完全理解了 hey 在做什么。

概念一：并发（Concurrency）——同时开工的"工人"数

🏃 想象一个餐厅：并发数就是同时服务顾客的服务员数量。

• 在 hey 中由-c参数控制，默认 50（即默认有 50 个 worker 同时发请求）
• 请求总数由-n控制，默认 200，且总请求数不能小于并发数（服务员不能比顾客还多）
• 并发越高，模拟的"同时在线用户"越多，对服务的压力越大

对应源码中Work结构体的两个字段N（总请求数）与C（并发 worker 数），见 requester/requester.go。

💡新手建议：从-c 50起步，逐步调高，观察延迟何时开始飙升——那个拐点就是服务容量的参考线。

概念二：QPS——限流视角的"每秒查询数"

⏱️QPS（Queries Per Second）表示每秒发起的查询数。它在 hey 里是输入：用-q参数给每个 worker 限速。

hey -q 10 -c 5 -z 30s https://example.com

含义：5 个并发 worker，每人限 10 QPS，持续压测 30 秒。这模拟的是"用户按固定节奏访问"的温和场景，而不是火力全开。

注意一个易错点：-q是每个 worker的限速，整体速率 ≈-c × -q（5 × 10 = 50 QPS）。

概念三：RPS——结果视角的"每秒响应数"

📊RPS（Requests Per Second）则是输出：整个压测跑完后，hey 告诉你平均每秒实际完成了多少个请求。

它在源码中的算法一目了然：总请求数 ÷ 总耗时，见 requester/report.go：

r.rps = float64(r.numRes) / r.total.Seconds()

QPS 和 RPS 有什么区别？

💡 没有限速时，RPS 越高越好；如果 RPS 上不去，往往要回头检查延迟是否太高。

概念四：延迟（Latency）——单个请求要等多久？

🐢延迟衡量的是一个请求从发出到收完响应的耗时。hey 会给你三个数字：

• Average：平均值
• Fastest / Slowest：最快与最慢

但平均值会"骗人"（一次极端慢请求就能拉高平均），所以 hey 额外提供了延迟分布（Percentiles）：

Latency distribution: 10% in 0.0520 secs 50% in 0.0870 secs 95% in 0.1500 secs 99% in 0.2200 secs

含义是：95% 的请求在 0.15 秒内完成——这比平均值更能反映真实用户体验。分位数的计算逻辑在 requester/report.go，默认统计 10%、25%、50%、75%、90%、95%、99% 七个档位。

报告中的**直方图（Response time histogram）**则把延迟切成 10 个桶，用■画出分布形状：

Response time histogram: 0.052 [ 3] |■ 0.071 [ 42] |████████████ 0.090 [ 95] |████████████████████████████

一眼就能看出延迟是"尖峰集中"还是"长尾拖沓"。

概念五：TTFB——首字节返回时间

🚀TTFB（Time To First Byte）指从写完请求到收到响应第一个字节的等待时间——也就是服务端"思考"花了多久，不含网络传输响应体的时间。

在 hey 中它对应报告里的resp wait行（CSV 输出中叫Response-delay），通过追踪GotFirstResponseByte事件精确计时，代码见 requester/requester.go。

为什么重要？

• TTFB 高：大概率是服务端计算慢、数据库查询慢、代码逻辑重
• TTFB 低但总延迟高：大概率是响应体太大、网络带宽不足

它是定位"性能瓶颈在服务端还是网络"的关键指标 🔍

一张表看懂 hey 输出报告

hey 默认输出 summary 报告（也可用-o csv导出每个请求的明细数据），各字段与概念的对应关系如下：

CSV 格式的完整 8 列说明写在 requester/print.go 的文件头注释中，字段汇总逻辑见 requester/report.go。

新手速查清单：压测前的 5 个自检问题 ✅

1. 并发设多少？-c从 50 起步，总请求数-n必须 ≥ 并发数
2. 要不要限速？模拟真实节奏用-q，火力全开则不加
3. 压多久？用-z 30s按时间跑，比按次数跑更贴近真实
4. 看哪个延迟？优先看 95%/99% 分位，别只信平均值
5. 瓶颈在哪？TTFB 高查服务端，resp read高查带宽

掌握这五大概念后，再配合 README.md 中的参数示例跑几轮压测，你就能独立完成一次有说服力的性能测试，并看懂每一份 Hey 压测报告了 🏁

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