Hey 压测合格标准如何快速制定 SLA 阈值与压测通过判据完整指南【免费下载链接】heyHTTP load generator, ApacheBench (ab) replacement项目地址: https://gitcode.com/GitHub_Trending/he/heyHey 是一款轻量级 HTTP 压测工具HTTP load generator常被视作 ApacheBench (ab) 的现代替代。本文带你用 Hey 做压测验收读懂压测报告里的关键指标快速制定 SLA 阈值P95/P99 延迟、错误率、QPS最后给出一套可直接套用的压测通过判据清单让压测是否合格不再靠感觉而是有标准可依。一、30 秒上手安装 Hey 并跑第一次压测Hey 的安装非常简单一条命令即可完成macOSbrew install heyLinux / Windows使用官方提供的二进制文件即可安装完成后一条命令就能发起压测hey -n 1000 -c 100 https://你的接口地址 含义以 100 个并发-c共发送 1000 个请求-n。这些核心参数的定义见 hey.go包括请求数、并发数、限流 QPS、超时和持续时长。常用压测参数速查表参数作用建议用法-n总请求数默认 200功能接口验收一般 1000 以上-c并发 worker 数默认 50按预估峰值并发设置-q每个 worker 的 QPS 限流模拟真实流量时启用-z持续压测时长如3m验证稳定性推荐 ≥ 3 分钟-o csv以 CSV 导出每次请求明细用于压测报告归档-t单请求超时秒数默认 20与 SLA 延迟阈值联动设置二、读懂 Hey 压测报告SLA 判定的 5 个关键指标Hey 跑完后会输出一份摘要报告Summary它的模板定义在 requester/print.go。这份报告就是制定 SLA 的原材料共 5 个板块值得逐个看懂1. Latency distribution延迟分布⭐ 最重要按百分位列出延迟如95% in 0.1234 secs、99% in 0.4567 secs。也就是说 95% 的请求耗时不超过该值。百分位的计算逻辑在 requester/report.go 中默认统计 10/25/50/75/90/95/99 七个分位。划重点制定 SLA 时看 P95、P99而不是平均值。平均值会把尖峰摊平掩盖用户真实感受到的卡顿。2. Requests/sec吞吐量压测总请求数除以总耗时即系统实际扛住的 QPS。它是系统能承载多少流量的直接证据。3. Status code distribution状态码分布验收类压测中200 之外的状态码500、502、504 等都应视为故障信号是错误率的第一个来源。4. Error distribution错误分布网络层错误连接超时、被拒绝等会单独统计如context deadline exceeded。它与状态码错误合并起来才是完整的错误率口径。5. Details 各阶段耗时报告把每次请求拆成 DNSdialup、DNS 查询、请求写出、等待首字节resp wait、读取响应五个阶段单请求明细的数据结构见 requester/requester.go。当延迟超标时用这组数据能迅速定位瓶颈在网络建连还是服务端处理。三、如何制定 SLA 阈值三大指标的取值方法有了报告下一步是把它翻译成可量化的 SLA 阈值。建议从三个维度定标准1. 延迟阈值以 P95 / P99 为纲P95绝大多数用户95%的体验上限适合面向 C 端的接口P99长尾用户1%的兜底上限适合对稳定性要求高的核心链路参考基线内部微服务接口 P99 ≤ 100ms对外 API P95 ≤ 300ms、P99 ≤ 500ms按业务实际调整。2. 错误率阈值核心链路建议 0 容忍核心交易/登录链路错误率 0%出现 5xx 即不合格一般查询接口可放宽到≤ 0.1%但需要记录并复核每一次错误原因。3. 吞吐量阈值QPS 必须达到设计目标压测前先确认系统设计的峰值 QPS 目标如 2000 QPS压测实测 Requests/sec 达标才算通过。注意用-t把单请求超时设为略大于 P99 阈值避免慢请求拖垮整体统计。四、压测通过判据清单5 条全过才算合格把上面的阈值固化成一张验收清单压测后逐项打勾 ✅#判据建议阈值示例对应 Hey 报告项1P95 延迟≤ 300msLatency distribution95%2P99 延迟≤ 500msLatency distribution99%3错误率5xx 网络错误 0%Status code Error distribution4吞吐量≥ 目标 QPSSummary 的Requests/sec5稳定性持续 3 分钟压测无错误堆积-z 3m全程报告⚠️判定规则以上 5 条只要有一条不满足本次压测即判不合格需要定位优化后重新压测而不是平均来看还行就放行。五、持续压测验证稳定性-z 3m与 CSV 报告归档单次跑-n 1000只能看瞬时表现真正的稳定性要看持续压力下的表现hey -c 100 -z 3m https://你的接口地址使用-z后 Hey 会持续压测指定时长此时忽略-n能暴露内存泄漏、连接池耗尽、GC 抖动等跑久了才出现的问题加上-o csv可将每次请求的 8 列明细响应总耗时、DNS建连、请求写出、等待、读响应、状态码、时间偏移等导出为 CSV字段说明见 requester/print.go方便存档和事后分析长尾请求。归档建议把压测命令 完整摘要报告 CSV 文件 日期 服务版本一起存档作为该版本的性能基线下次版本回归时直接对比。六、常见误区与最佳实践 ⚠️❌只看平均延迟→ 平均值会掩盖尖峰必须看 P95/P99❌压测一次就下结论→ 至少跑 3 分钟持续压测并重复 2~3 次取稳定值❌不记录压测参数→-n/-c/-q/-t参数不同结果不可比务必写进报告❌用生产环境直接压→ 先在预发环境做压测流量要与真实用户流量隔离✅超时设置与 SLA 联动→-t设为 P99 阈值的 1.5~2 倍及时切掉异常慢请求。小结用 Hey 做压测验收的完整路径是定目标 → 跑压测 → 读报告 → 对照判据 → 归档。记住三个核心动作以 P95/P99 定延迟阈值、以 0 容忍或 0.1% 定错误率、以实测 QPS 对标设计目标再用一份 5 条判据的清单做最终裁决。标准定得越具体压测合格这三个字就越有说服力。【免费下载链接】heyHTTP load generator, ApacheBench (ab) replacement项目地址: https://gitcode.com/GitHub_Trending/he/hey创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Hey 压测合格标准：如何快速制定 SLA 阈值与压测通过判据（完整指南）
Hey 压测合格标准如何快速制定 SLA 阈值与压测通过判据完整指南【免费下载链接】heyHTTP load generator, ApacheBench (ab) replacement项目地址: https://gitcode.com/GitHub_Trending/he/heyHey 是一款轻量级 HTTP 压测工具HTTP load generator常被视作 ApacheBench (ab) 的现代替代。本文带你用 Hey 做压测验收读懂压测报告里的关键指标快速制定 SLA 阈值P95/P99 延迟、错误率、QPS最后给出一套可直接套用的压测通过判据清单让压测是否合格不再靠感觉而是有标准可依。一、30 秒上手安装 Hey 并跑第一次压测Hey 的安装非常简单一条命令即可完成macOSbrew install heyLinux / Windows使用官方提供的二进制文件即可安装完成后一条命令就能发起压测hey -n 1000 -c 100 https://你的接口地址 含义以 100 个并发-c共发送 1000 个请求-n。这些核心参数的定义见 hey.go包括请求数、并发数、限流 QPS、超时和持续时长。常用压测参数速查表参数作用建议用法-n总请求数默认 200功能接口验收一般 1000 以上-c并发 worker 数默认 50按预估峰值并发设置-q每个 worker 的 QPS 限流模拟真实流量时启用-z持续压测时长如3m验证稳定性推荐 ≥ 3 分钟-o csv以 CSV 导出每次请求明细用于压测报告归档-t单请求超时秒数默认 20与 SLA 延迟阈值联动设置二、读懂 Hey 压测报告SLA 判定的 5 个关键指标Hey 跑完后会输出一份摘要报告Summary它的模板定义在 requester/print.go。这份报告就是制定 SLA 的原材料共 5 个板块值得逐个看懂1. Latency distribution延迟分布⭐ 最重要按百分位列出延迟如95% in 0.1234 secs、99% in 0.4567 secs。也就是说 95% 的请求耗时不超过该值。百分位的计算逻辑在 requester/report.go 中默认统计 10/25/50/75/90/95/99 七个分位。划重点制定 SLA 时看 P95、P99而不是平均值。平均值会把尖峰摊平掩盖用户真实感受到的卡顿。2. Requests/sec吞吐量压测总请求数除以总耗时即系统实际扛住的 QPS。它是系统能承载多少流量的直接证据。3. Status code distribution状态码分布验收类压测中200 之外的状态码500、502、504 等都应视为故障信号是错误率的第一个来源。4. Error distribution错误分布网络层错误连接超时、被拒绝等会单独统计如context deadline exceeded。它与状态码错误合并起来才是完整的错误率口径。5. Details 各阶段耗时报告把每次请求拆成 DNSdialup、DNS 查询、请求写出、等待首字节resp wait、读取响应五个阶段单请求明细的数据结构见 requester/requester.go。当延迟超标时用这组数据能迅速定位瓶颈在网络建连还是服务端处理。三、如何制定 SLA 阈值三大指标的取值方法有了报告下一步是把它翻译成可量化的 SLA 阈值。建议从三个维度定标准1. 延迟阈值以 P95 / P99 为纲P95绝大多数用户95%的体验上限适合面向 C 端的接口P99长尾用户1%的兜底上限适合对稳定性要求高的核心链路参考基线内部微服务接口 P99 ≤ 100ms对外 API P95 ≤ 300ms、P99 ≤ 500ms按业务实际调整。2. 错误率阈值核心链路建议 0 容忍核心交易/登录链路错误率 0%出现 5xx 即不合格一般查询接口可放宽到≤ 0.1%但需要记录并复核每一次错误原因。3. 吞吐量阈值QPS 必须达到设计目标压测前先确认系统设计的峰值 QPS 目标如 2000 QPS压测实测 Requests/sec 达标才算通过。注意用-t把单请求超时设为略大于 P99 阈值避免慢请求拖垮整体统计。四、压测通过判据清单5 条全过才算合格把上面的阈值固化成一张验收清单压测后逐项打勾 ✅#判据建议阈值示例对应 Hey 报告项1P95 延迟≤ 300msLatency distribution95%2P99 延迟≤ 500msLatency distribution99%3错误率5xx 网络错误 0%Status code Error distribution4吞吐量≥ 目标 QPSSummary 的Requests/sec5稳定性持续 3 分钟压测无错误堆积-z 3m全程报告⚠️判定规则以上 5 条只要有一条不满足本次压测即判不合格需要定位优化后重新压测而不是平均来看还行就放行。五、持续压测验证稳定性-z 3m与 CSV 报告归档单次跑-n 1000只能看瞬时表现真正的稳定性要看持续压力下的表现hey -c 100 -z 3m https://你的接口地址使用-z后 Hey 会持续压测指定时长此时忽略-n能暴露内存泄漏、连接池耗尽、GC 抖动等跑久了才出现的问题加上-o csv可将每次请求的 8 列明细响应总耗时、DNS建连、请求写出、等待、读响应、状态码、时间偏移等导出为 CSV字段说明见 requester/print.go方便存档和事后分析长尾请求。归档建议把压测命令 完整摘要报告 CSV 文件 日期 服务版本一起存档作为该版本的性能基线下次版本回归时直接对比。六、常见误区与最佳实践 ⚠️❌只看平均延迟→ 平均值会掩盖尖峰必须看 P95/P99❌压测一次就下结论→ 至少跑 3 分钟持续压测并重复 2~3 次取稳定值❌不记录压测参数→-n/-c/-q/-t参数不同结果不可比务必写进报告❌用生产环境直接压→ 先在预发环境做压测流量要与真实用户流量隔离✅超时设置与 SLA 联动→-t设为 P99 阈值的 1.5~2 倍及时切掉异常慢请求。小结用 Hey 做压测验收的完整路径是定目标 → 跑压测 → 读报告 → 对照判据 → 归档。记住三个核心动作以 P95/P99 定延迟阈值、以 0 容忍或 0.1% 定错误率、以实测 QPS 对标设计目标再用一份 5 条判据的清单做最终裁决。标准定得越具体压测合格这三个字就越有说服力。【免费下载链接】heyHTTP load generator, ApacheBench (ab) replacement项目地址: https://gitcode.com/GitHub_Trending/he/hey创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考