HTTP benchmarking tools: wrk, hey, oha, ab and more

The command-line HTTP benchmarking tools most teams reach for are wrk, wrk2, hey, oha, ab (Apache Bench), bombardier, autocannon and h2load. Use wrk2 when you need a constant request rate and honest tail latency, hey or oha for a quick check that also speaks HTTP/2, h2load when HTTP/2 or HTTP/3 is the thing under test, and autocannon when your team works in Node.js.

We have not run these tools against each other, so there are no speed numbers or “fastest” verdicts here. Facts come from each project’s own repository, manual or releases page (checked on 9 October 2026); the “choose” notes are our judgement.

Why does it matter whether a tool fixes the rate?

A tool that holds a fixed number of connections sends less when the server slows down, so its latency figures leave out the time requests spent waiting. A fixed-rate tool keeps sending on schedule, and the slowdown shows up in the percentiles.

Most tools here run a set number of connections or workers (-c), each waiting for a response before sending more. The wrk2 README calls the resulting blind spot Coordinated Omission and times each request from when it was supposed to be sent. Vegeta also holds a constant rate; see our open source load testing tools roundup. oha and autocannon can correct their latency for the same effect when a rate is set, while hey and bombardier document their rate options as limits only.

Is wrk still worth using?

Yes, for a quick look at how much load one machine can push at an endpoint, read with the caveat above. Its newest tag dates from February 2021.

wrk is written in C and keeps a fixed number of connections open across several threads. Optional LuaJIT scripts can build requests, process responses and write custom reports, and make builds it together with the bundled LuaJIT and OpenSSL. It prints average, standard deviation and maximum latency; --latency adds the 50th, 75th, 90th and 99th percentiles.

Choose wrk2 instead when you need a fixed request rate or tail latency you can trust during a slowdown.

When do you need wrk2 instead of wrk?

When the question is how latency behaves at a given request rate. wrk2 holds that rate constant and records every latency in an HdrHistogram.

wrk2 adds a throughput argument (-R, requests per second) to wrk. --latency prints the full percentile spectrum and --u_latency adds uncorrected figures for comparison. Its README warns that runs under 10 to 20 seconds may not be useful because of a 10-second calibration period, and calls the project experimental. It has no releases, and its Makefile builds a binary also named wrk, so keep the two apart.

Choose oha or autocannon instead when you want a rate setting with latency correction from a project that is still maintained.

Are hey and oha interchangeable?

For quick checks, largely: both run a pool of workers for a request count or a duration, and both speak HTTP/2. They differ in rate limiting and in what you see during a run.

hey is a small Go program with prebuilt binaries for Linux, macOS and Windows and a Homebrew formula. -q limits queries per second for each worker, -h2 turns on HTTP/2, and the summary includes a response time histogram and a latency distribution, or CSV with -o csv.

oha is written in Rust, was inspired by hey and shows a live terminal UI. Its -q sets one overall rate, --latency-correction corrects for coordinated omission, and --http-version accepts 1.1, 2 and, in an experimental build, 3. It installs with cargo, Homebrew, winget or pacman and can write JSON or CSV.

Choose hey instead when a per-worker limit fits how you think about load; choose oha for HTTP/3, JSON or latency correction.

Should you still use ab?

For a quick check on a machine where it is already installed, yes. ab ships with the Apache HTTP Server, and its own manual lists known limits.

ab takes a request count (-n) and a concurrency level (-c), with no rate or HTTP/2 option, and uses KeepAlive only with -k. Its output ends with the percentage of requests served within a given time, and it can write those percentages to CSV (-e) or every measurement to a gnuplot file (-g). The manual’s Bugs section says ab does not implement HTTP/1.x fully and warns that its heavy string parsing can make you measure ab’s own performance.

Choose hey or oha instead when you need HTTP/2, a rate limit or keep-alive by default.

What are bombardier and autocannon good for?

bombardier is a Go tool with optional HTTP/2 and a rate limit. autocannon suits Node.js teams, because it also runs as a library inside a Node script.

bombardier uses the fasthttp client by default and switches to Go’s net/http client with --http1 or --http2. -r sets a rate limit, -l prints the 50th, 75th, 90th and 99th percentiles, and -o json makes the result machine-readable.

autocannon describes itself as an HTTP/1.1 tool with pipelining and HTTPS, installed with npm i autocannon -g. -R caps the overall rate and -r the rate per connection, with latency corrected for coordinated omission when either is set. Its table shows the 2.5th, 50th, 97.5th and 99th percentiles, -l prints them all and -j writes JSON.

Choose autocannon instead of bombardier when your benchmarks live in a Node.js test suite, and bombardier when you need HTTP/2.

Which tool is built for HTTP/2 and HTTP/3?

h2load. It comes from the nghttp2 project, prefers HTTP/2, and can force HTTP/1.1 or, when built with support, HTTP/3.

h2load is compiled with nghttp2 by passing --enable-app to ./configure. Besides clients (-c), it sets concurrent streams per client (-m) to load-test multiplexing, and --rps sets requests per second for each client. The manual reports min, max, mean, median, p95 and p99 for request time, connect time and time to first byte. HTTP/3 support is marked experimental.

Choose oha instead when you want HTTP/2 with fewer options and a live view.

When should you move from a benchmark to a real load test?

When the question involves user journeys, more load than one machine can generate, or traffic from where your users are.

Every tool here fires simple requests from one machine, and the h2load guide notes that the client itself can become the bottleneck. Move to a load testing tool when you need logins, multi-step journeys or think time, when traffic must come from several regions, or when a test should pass or fail in CI. Our guide on how to run a load test covers that step by step, and k6 vs Artillery compares two scriptable tools.

LoadFocus, the publisher of this site, runs load tests for websites and APIs from 25 cloud regions, with JMeter, k6 or no-code tests. If your benchmark is a request you already send with curl, its free cURL to k6 converter turns that command into a k6 script in your browser.

FAQ

What is the difference between wrk and wrk2? wrk2 is a fork of wrk that sends requests at a constant rate set with -R and times each request from when it should have been sent. wrk keeps a fixed number of connections busy and has no rate setting.

Which HTTP benchmarking tools support HTTP/2? hey, oha, bombardier, h2load and Vegeta, according to their documentation. wrk and wrk2 do not document it, autocannon describes itself as HTTP/1.1 and ab has no HTTP/2 option.

Related reading

• Open source load testing tools: six options reviewed
• Coordinated omission: what it is and how to avoid it
• WebSocket load testing tools: six options compared
• Tail latency: what it is and how to measure it
• redis-benchmark: how to use it and read its numbers

The technical claims in this article have not been independently reviewed.