拓冰网站定制 
Hey的Requests/sec真相RPS到底怎么算为什么和-q目标值不同【免费下载链接】heyHTTP load generator, ApacheBench (ab) replacement项目地址: https://gitcode.com/GitHub_Trending/he/heyhey 是一款轻量级的 HTTP 压测工具ApacheBench/ab 的替代品用一条命令就能对 Web 应用发起真实流量并输出 RPS、延迟分布等统计报告。很多新手会疑惑明明用-q设了每秒请求数报告里的Requests/sec却对不上目标值。本文带你从源码角度弄懂 RPS 的计算方式并给出能踩中目标 QPS 的正确用法。一分钟认识 hey 压测工具hey 的核心理念只有三件事发压、计时、汇总。-n总请求数默认 200-c并发 worker 数默认 50-q每个 worker 的限速QPS/worker默认不限速-z压测时长如-z 30s完整参数说明见 README.md。典型用法hey -n 1000 -c 100 https://example.comRequests/sec 到底是怎么算出来的答案藏在报告生成逻辑里一行代码说清见 requester/report.goRPS 总完成请求数(numRes) ÷ 总耗时(秒)两个数字的来源分别是变量来源关键点numRes每收到一个请求结果就 1requester/report.go⚠️失败的请求也计入total从压测启动b.start计时到最后一个 worker 干完活为止requester/requester.go包含最慢那条尾巴请求这带来两个容易被忽略的真相RPS 包含报错请求即使服务端返回 5xx 或超时失败numRes 同样会加一但平均延迟统计只算成功的请求分母是墙钟时间从启动那一刻算到最慢的 worker 结束而不是最后一个请求发出的时刻。所以Requests/sec是实测吞吐不是计划吞吐。为什么 RPS 总是和 -q 目标值不同-q 是每 worker限速不是全局限速这是最大的认知陷阱。-q的官方定义是Rate limit, in queries per second (QPS)per worker见 hey.go。每个 worker 内部用一个定时器按1e6/q微秒的节奏放行请求requester/requester.go。hey -q 10 -c 5 -z 30s https://example.com理论上限 10 QPS × 5 workers 50 RPS而不是 10 RPS。想精确控制总 QPS请自己换算-c的值目标总 RPS ÷ 每个 worker 的 -q 需要的 worker 数服务端变慢时限速器会自动失效定时器只在worker 空闲时起作用。如果单次请求的响应时间超过了定时器间隔worker 就一直在等响应实际速率被服务端延迟卡住而不是被-q卡住。这就是经典的小公式Littles Law 的直观版当延迟 1/-q 时实际 RPS ≈ 并发数 ÷ 平均响应时间例如-q 100 -c 5理论 500 RPS但若平均响应耗时 200ms每个 worker 每秒只能完成 5 个请求实测 RPS ≈ 5 × 5 25只有目标的 5%。此时提高 RPS 的唯一办法是加并发-c而不是加-q。总时长还包含收尾尾巴压测结束时正在飞行中的请求仍会计入 numRes而 total 也会持续到最慢的 worker 结束。因此短时压测如-z 3s里RPS 往往系统性偏低分母被拉长但请求没有等比例增加。压测时间越长实测值越贴近理论值。如何正确设置 -q 与 -c最快逼近目标 RPS先算总账目标 RPS ÷ worker 数 单 worker -q 值-q设为略低于该值的整数留足时长至少跑 30s-z 30s摊薄启动与收尾误差看报错分布报告底部会输出Error distribution模板见 requester/print.go有报错说明瓶颈在服务端此时 RPS 偏低是正常现象需要逐请求数据时用-o csv导出每行包含响应耗时、DNS、建连、写请求、等首字节等 8 列指标方便二次分析。# 目标约 50 RPS每 worker 10 QPS × 5 worker压测 30 秒 hey -q 10 -c 5 -z 30s https://example.com小结一句话记住 hey 的 RPSRequests/sec 完成的请求总数含失败÷ 从启动到结束的总秒数是事后统计不是限速目标-q是每个 worker的天花板全局目标要乘上-c当服务端变慢时延迟决定 RPS而不是 -q。理解了这几点你就能把 hey 的每份压测报告读得明明白白也能一眼判断RPS 上不去到底是参数没设对还是系统真的扛不住了 【免费下载链接】heyHTTP load generator, ApacheBench (ab) replacement项目地址: https://gitcode.com/GitHub_Trending/he/hey创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Hey的Requests/sec真相：RPS到底怎么算？为什么和-q目标值不同？
Hey的Requests/sec真相RPS到底怎么算为什么和-q目标值不同【免费下载链接】heyHTTP load generator, ApacheBench (ab) replacement项目地址: https://gitcode.com/GitHub_Trending/he/heyhey 是一款轻量级的 HTTP 压测工具ApacheBench/ab 的替代品用一条命令就能对 Web 应用发起真实流量并输出 RPS、延迟分布等统计报告。很多新手会疑惑明明用-q设了每秒请求数报告里的Requests/sec却对不上目标值。本文带你从源码角度弄懂 RPS 的计算方式并给出能踩中目标 QPS 的正确用法。一分钟认识 hey 压测工具hey 的核心理念只有三件事发压、计时、汇总。-n总请求数默认 200-c并发 worker 数默认 50-q每个 worker 的限速QPS/worker默认不限速-z压测时长如-z 30s完整参数说明见 README.md。典型用法hey -n 1000 -c 100 https://example.comRequests/sec 到底是怎么算出来的答案藏在报告生成逻辑里一行代码说清见 requester/report.goRPS 总完成请求数(numRes) ÷ 总耗时(秒)两个数字的来源分别是变量来源关键点numRes每收到一个请求结果就 1requester/report.go⚠️失败的请求也计入total从压测启动b.start计时到最后一个 worker 干完活为止requester/requester.go包含最慢那条尾巴请求这带来两个容易被忽略的真相RPS 包含报错请求即使服务端返回 5xx 或超时失败numRes 同样会加一但平均延迟统计只算成功的请求分母是墙钟时间从启动那一刻算到最慢的 worker 结束而不是最后一个请求发出的时刻。所以Requests/sec是实测吞吐不是计划吞吐。为什么 RPS 总是和 -q 目标值不同-q 是每 worker限速不是全局限速这是最大的认知陷阱。-q的官方定义是Rate limit, in queries per second (QPS)per worker见 hey.go。每个 worker 内部用一个定时器按1e6/q微秒的节奏放行请求requester/requester.go。hey -q 10 -c 5 -z 30s https://example.com理论上限 10 QPS × 5 workers 50 RPS而不是 10 RPS。想精确控制总 QPS请自己换算-c的值目标总 RPS ÷ 每个 worker 的 -q 需要的 worker 数服务端变慢时限速器会自动失效定时器只在worker 空闲时起作用。如果单次请求的响应时间超过了定时器间隔worker 就一直在等响应实际速率被服务端延迟卡住而不是被-q卡住。这就是经典的小公式Littles Law 的直观版当延迟 1/-q 时实际 RPS ≈ 并发数 ÷ 平均响应时间例如-q 100 -c 5理论 500 RPS但若平均响应耗时 200ms每个 worker 每秒只能完成 5 个请求实测 RPS ≈ 5 × 5 25只有目标的 5%。此时提高 RPS 的唯一办法是加并发-c而不是加-q。总时长还包含收尾尾巴压测结束时正在飞行中的请求仍会计入 numRes而 total 也会持续到最慢的 worker 结束。因此短时压测如-z 3s里RPS 往往系统性偏低分母被拉长但请求没有等比例增加。压测时间越长实测值越贴近理论值。如何正确设置 -q 与 -c最快逼近目标 RPS先算总账目标 RPS ÷ worker 数 单 worker -q 值-q设为略低于该值的整数留足时长至少跑 30s-z 30s摊薄启动与收尾误差看报错分布报告底部会输出Error distribution模板见 requester/print.go有报错说明瓶颈在服务端此时 RPS 偏低是正常现象需要逐请求数据时用-o csv导出每行包含响应耗时、DNS、建连、写请求、等首字节等 8 列指标方便二次分析。# 目标约 50 RPS每 worker 10 QPS × 5 worker压测 30 秒 hey -q 10 -c 5 -z 30s https://example.com小结一句话记住 hey 的 RPSRequests/sec 完成的请求总数含失败÷ 从启动到结束的总秒数是事后统计不是限速目标-q是每个 worker的天花板全局目标要乘上-c当服务端变慢时延迟决定 RPS而不是 -q。理解了这几点你就能把 hey 的每份压测报告读得明明白白也能一眼判断RPS 上不去到底是参数没设对还是系统真的扛不住了 【免费下载链接】heyHTTP load generator, ApacheBench (ab) replacement项目地址: https://gitcode.com/GitHub_Trending/he/hey创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考