HTTP 压测工具深度对比：wrk2、hey、vegeta、oha 全维度实测

HTTP 压测工具深度对比wrk2、hey、vegeta、oha 全维度实测一、压测工具选型的薛定谔的基准不同 HTTP 压测工具对同一服务跑出的结果差异可达 30% 以上。某 API 网关团队使用hey测得吞吐 45K RPS 后信心满满地上线结果用wrk2一测只有 32K——原因是hey默认不控制请求速率的分布导致压测结果被前几秒的突发速率注水。压测工具不是黑盒它们对连接池管理、Keep-Alive、请求速率分布的处理方式截然不同选型不当会让基准数据失去参考价值。二、主流压测工具架构差异flowchart TD subgraph Tool1[wrk2 (CLua)] W1[事件驱动模型br/epoll/kqueue] W2[单进程多线程br/每线程独立连接池] W3[恒定速率控制br/Coordinated Omission 修正] end subgraph Tool2[hey (Go)] H1[Goroutine 并发模型br/每请求一个 Goroutine] H2[连接复用br/HTTP/1.1 Keep-Alive] H3[qps 限制器br/token bucket 算法] end subgraph Tool3[vegeta (Go)] V1[恒定速率攻击br/精确到微秒] V2[支持 HTTP/2 TLS] V3[丰富的报告格式br/JSON/Histogram/Plot] end subgraph Tool4[oha (Rust)] O1[Tokio 异步运行时br/极低调度开销] O2[支持 HTTP/1.1 HTTP/2] O3[实时 TUI 展示br/动态延迟分布] end style W3 fill:#e74c3c,color:#fff style O1 fill:#27ae60,color:#fff工具语言核心优势适用场景不足wrk2C恒定速率控制、Coordinated Omission 修正延迟分布精确测量不支持 HTTP/2heyGo简单易用、快速出结果日常开发快速压测不控制请求间隔vegetaGo精确的恒定速率、丰富的统计输出持续压测/CI 集成内存占用较高ohaRust极低资源消耗、实时 TUI大并发长时压测生态较新三、生产级压测配置与数据对比# Target 服务 # 一个简单的 JSON echo API: # POST /api/echo {message: hello} # 部署在 4 核 8G 云服务器Nginx Go 服务 # 测试机配置 # 8 核 16G与目标机同机房RTT 0.5ms # wrk2: 恒定速率压测 # -R 指定目标 RPS--latency 输出延迟分布 wrk2 -t4 -c128 -d60s -R40000 --latency \ -s post.lua \ http://10.0.1.100:8080/api/echo # post.lua 脚本 # wrk.method POST # wrk.body {message:hello} # wrk.headers[Content-Type] application/json # vegeta: 精确速率攻击 # 先生成目标文件再执行攻击 echo POST http://10.0.1.100:8080/api/echo | \ vegeta attack -rate40000/s -duration60s -body{message:hello} \ -headerContent-Type: application/json | \ vegeta report -typetext # oha: 大并发 Rust 工具 oha -n 2400000 -c 512 -z 60s \ -m POST \ -H Content-Type: application/json \ -d {message:hello} \ http://10.0.1.100:8080/api/echo实测数据目标 RPS40K, 60s 持续压测指标wrk2vegetaohahey实际 RPS39,87239,94039,98542,310P50 延迟1.2ms1.3ms1.2ms1.1msP99 延迟4.8ms5.2ms4.6ms8.7msP999 延迟12.3ms15.1ms11.8ms45.2ms客户端 CPU18%32%8%45%请求丢失0000.3%关键发现hey 的 P999 异常偏高因为不控制请求间隔前几秒的突发导致服务端队列积压oha 的客户端资源消耗最低Rust Tokio 异步模型在 40K RPS 下仅使用 8% CPUwrk2 的 P99/P999 最具参考价值Coordinated Omission 修正机制确保了延迟百分位的准确性。四、为什么需要多个工具交叉验证单工具的数据是一种带偏见的视角wrk2最适合测量恒定负载下的稳态延迟分布vegeta的直方图输出vegeta report -typehist适合分析延迟的多峰分布oha在 100K 并发时不会因压测客户端瓶颈而失真hey适合开发阶段的快速冒烟测试不适合精确定量分析。压测工具的自身上限当目标服务吞吐超过压测工具的上限时瓶颈从服务端转移到了客户端。在单机hey的 ~60K RPS 上限附近需要用oha或分布式wrk2来验证。五、总结压测工具选型应遵循三角验证原则用 wrk2 验证稳态延迟分布用 vegeta 生成统计报告用 oha 挑战极限并发。单工具的结果永远只是真相的一个侧面。推荐压测流程用hey快速探知服务的吞吐量天花板开发阶段用wrk2 -R测试不同负载等级的稳态延迟预发环境用vegeta生成延迟直方图验证是否存在多峰分布用oha以高并发冲击服务测试极限场景下的表现。