wrk vs k6 vs oha: Which HTTP Benchmark Tool for Which Job
wrk vs k6 vs oha is the comparison teams actually need when they are about to freeze a lab image. These three binaries cover most honest HTTP work in 2026. They are not interchangeable. Treating them as one “load tool” is how a ceiling test becomes a journey test wearing the wrong flags.
This page assigns a job to each, shows where wrk vs k6 vs oha overlap just enough to confuse a reviewer, and gives a one-paragraph rule you can paste into a README.
wrk and wrk2
wrk is the classic C hammer: multi-threaded, Lua-scriptable, extremely fast on HTTP/1.1, and quiet upstream. wrk2 adds a target rate and coordinated-omission-aware latency. wrkx and similar forks keep the lineage usable now that original wrk is quiet. Use this family when you want the ceiling of a plaintext or JSON endpoint and you already know the Lua you need.
Do not use original wrk as your only latency source under saturation. Coordinated omission will flatter the server. That sentence is why wrk2 still exists, and why a wrk vs k6 vs oha bake-off that only runs original wrk is incomplete.
k6
k6 is the scenario tool. JavaScript scripts, checks, thresholds, arrival-rate executors, gRPC and WebSocket, a commercial path if you want cloud generators. Use k6 when the question involves think time, mixed routes, or a budget that should fail a build. Do not use k6 as your only microbenchmark client if you are chasing millions of RPS from one box. That is the wrong sport, and it is the usual way wrk vs k6 vs oha threads go off the rails.
export const options = {
scenarios: {
json: { executor: 'constant-arrival-rate', rate: 8000, duration: '45s', preAllocatedVUs: 200 }
},
thresholds: {
http_req_failed: ['rate<0.001'],
http_req_duration: ['p(99)<12']
}
};oha
oha is the 2026 laptop default for many labs. Rust, optional TUI, JSON and CSV output, HTTP/2, experimental HTTP/3, latency-correction flag. Use oha when you want a serious single-URL run in one command and a file you can archive next to a Git SHA. The TUI is how people discover it. The JSON is why it belongs in the wrk vs k6 vs oha shortlist.
oha -z 45s -c 256 --latency-correction -j http://10.0.0.8:8080/json > oha.jsonThe rule
Ceiling tests with wrk2 or oha. Journey tests and CI comments with k6. If you only install two binaries on a developer machine, install oha and k6. If you only install one, you will misuse it. That is the entire wrk vs k6 vs oha decision once the jobs are named.
| Question | Reach for |
|---|---|
| How high can this endpoint go on HTTP/1.1? | wrk2 or oha |
| What is p99 at a fixed arrival rate? | oha or vegeta, then k6 |
| Does this user journey stay in budget? | k6 |
| Need HTTP/2 or HTTP/3 quickly? | oha, then h2load |
| Need a PR gate with thresholds? | k6 |
When wrk vs k6 vs oha numbers disagree on the same URL, you have a client story. Publish both runs and look at client CPU. Tools are part of the system until proven otherwise.
Sibling long-tails: bombardier HTTP benchmark and HTTP load generator comparison 2026.
FAQ
Is wrk dead? Upstream is quiet. The job is not. Use a maintained fork if you need HTTP/1.1 ceilings with Lua.
Does oha replace wrk2? For many teams, yes. Keep wrk2 if you already have Lua scripts you trust.
Can k6 do ceilings? It can hammer a URL. It will usually lose a generator-limited race to wrk2 or oha. Do not crown a framework on that race.
Name the job, then pick from wrk vs k6 vs oha. Do not pick a mascot first.
Mistakes people make around wrk vs k6 vs oha
The first mistake is treating wrk vs k6 vs oha as a slogan instead of a scoped experiment. The second is copying a command from a chat log without pinning the client version. The third is publishing a peak while dropping the error column. Any one of those three will make a later review of wrk vs k6 vs oha feel like starting over.
A fourth mistake is mixing clusters. The seed HTTP benchmark tools is allowed to inform this page. A composite from an unrelated seed is not allowed to finish the claim. If someone pastes a plaintext crown into a discussion of wrk vs k6 vs oha, ask which protocol, which payload, and which error gate they used. If they cannot answer, the paste is decoration.
A fifth mistake is skipping warm-up and then blaming the framework. JIT runtimes, page cache, and TLS session tickets all distort the first seconds. How you treat those seconds is part of wrk vs k6 vs oha whether or not the original brief mentioned them.
Checklist before you claim wrk vs k6 vs oha
- One-sentence hypothesis that contains the phrase wrk vs k6 vs oha or an equivalent measurement goal.
- Frozen artifact: digest, flags, workers, runtime version.
- Client and server on disjoint cores or separate machines.
- Warm-up that is not scored.
- At least three accepted samples with an error gate.
- p50, p95, p99, successful RPS, RSS, and the exact command.
- A note on whether the client or the server hit the wall first.
- A link to sibling long-tails in the HTTP benchmark tools cluster.
If a box on that list is empty, you are not done with wrk vs k6 vs oha. You are drafting. Drafts can live in a branch. They should not live in a decision memo.
Who owns wrk vs k6 vs oha inside a company
Give the work a code owner. Platform teams usually own the harness. Product teams usually own the hypothesis, because only they know which route is expensive. Finance does not own wrk vs k6 vs oha, but they will quote it. Write the sentence they are allowed to quote and put it at the top of the report.
On-call owns the dashboard that wrk vs k6 vs oha is supposed to move. If on-call cannot find the panel in two minutes, the study will not change operations. That is not a documentation nit. That is how laboratory work dies after the launch channel goes quiet.
Security and privacy review the payload and the logs. A test that ships real user bodies into a load generator is not a study of wrk vs k6 vs oha. It is an incident with extra steps. Use synthetic documents that match production shape.
Worked example in the HTTP benchmark tools cluster
Suppose two engineers disagree about wrk vs k6 vs oha after a runtime bump. They rerun the same pinned command on the reserved instance family. One run is client bound. The other used HTTP/2 without saying so. After both mistakes are labeled, the delta shrinks to a number that no longer funds a rewrite. That outcome is a success. Studies that only count rewrites as success will stay loud and stay wrong.
Suppose instead the rerun confirms a 35% p99 improvement on the route that is 40% of CPU. Then wrk vs k6 vs oha has earned a migration design, not a migration. The design still needs an APM row, a rollback, and a field check. Lab wins that skip those three become next quarter’s incident review.
Keep raw JSON next to the Git SHA. If you cannot point at a file, you do not have a result for wrk vs k6 vs oha. You have a memory. Memories do not survive staffing changes. Put the file path in the ticket before the meeting so the meeting cannot become a debate about vibes.
If this page is the first time someone on the team has seen the phrase wrk vs k6 vs oha, send them the seed overview for HTTP benchmark tools after they finish the checklist, not before. Reading the cluster in the wrong order is how long-tails collapse back into a single generic argument. Keep the long-tail sharp. That is the only reason this article exists as its own URL.