Hey压测概念速成课新手必懂的并发、QPS、RPS、延迟与TTFB五大核心概念【免费下载链接】heyHTTP load generator, ApacheBench (ab) replacement项目地址: https://gitcode.com/GitHub_Trending/he/heyHey 是一款用 Go 编写的轻量级HTTP 压测工具load generator常被用作 ApacheBenchab的替代品。本文将用 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——限流视角的每秒查询数⏱️QPSQueries Per Second表示每秒发起的查询数。它在 hey 里是输入用-q参数给每个 worker 限速。hey -q 10 -c 5 -z 30s https://example.com含义5 个并发 worker每人限 10 QPS持续压测 30 秒。这模拟的是用户按固定节奏访问的温和场景而不是火力全开。注意一个易错点-q是每个 worker的限速整体速率 ≈-c × -q5 × 10 50 QPS。概念三RPS——结果视角的每秒响应数RPSRequests Per Second则是输出整个压测跑完后hey 告诉你平均每秒实际完成了多少个请求。它在源码中的算法一目了然总请求数 ÷ 总耗时见 requester/report.gor.rps float64(r.numRes) / r.total.Seconds()QPS 和 RPS 有什么区别对比项QPSRPS角色压测的输入限速压测的结果性能hey 对应-q参数报告中Requests/sec比喻你踩油门踩多猛车速表显示跑多快 没有限速时RPS 越高越好如果 RPS 上不去往往要回头检查延迟是否太高。概念四延迟Latency——单个请求要等多久延迟衡量的是一个请求从发出到收完响应的耗时。hey 会给你三个数字Average平均值Fastest / Slowest最快与最慢但平均值会骗人一次极端慢请求就能拉高平均所以 hey 额外提供了延迟分布PercentilesLatency 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——首字节返回时间TTFBTime To First Byte指从写完请求到收到响应第一个字节的等待时间——也就是服务端思考花了多久不含网络传输响应体的时间。在 hey 中它对应报告里的resp wait行CSV 输出中叫Response-delay通过追踪GotFirstResponseByte事件精确计时代码见 requester/requester.go。为什么重要TTFB 高大概率是服务端计算慢、数据库查询慢、代码逻辑重TTFB 低但总延迟高大概率是响应体太大、网络带宽不足它是定位性能瓶颈在服务端还是网络的关键指标 一张表看懂 hey 输出报告hey 默认输出 summary 报告也可用-o csv导出每个请求的明细数据各字段与概念的对应关系如下报告字段对应概念一句话理解Requests/secRPS整体每秒完成多少请求Average / Fastest / Slowest延迟单个请求快慢Latency distribution延迟分布99% 用户等多久resp waitTTFB服务端思考了多久DNSdialup连接建立TCP 建连花了多久req write写请求把请求发出去的时间resp read读响应收完响应体的时间CSV 格式的完整 8 列说明写在 requester/print.go 的文件头注释中字段汇总逻辑见 requester/report.go。新手速查清单压测前的 5 个自检问题 ✅并发设多少-c从 50 起步总请求数-n必须 ≥ 并发数要不要限速模拟真实节奏用-q火力全开则不加压多久用-z 30s按时间跑比按次数跑更贴近真实看哪个延迟优先看 95%/99% 分位别只信平均值瓶颈在哪TTFB 高查服务端resp read高查带宽掌握这五大概念后再配合 README.md 中的参数示例跑几轮压测你就能独立完成一次有说服力的性能测试并看懂每一份 Hey 压测报告了 【免费下载链接】heyHTTP load generator, ApacheBench (ab) replacement项目地址: https://gitcode.com/GitHub_Trending/he/hey创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考