Bombardier HTTP Benchmark: When the Go Hammer Is Enough

A bombardier HTTP benchmark is the right first pass when a team wants HTTP/1.1 or HTTP/2 ceilings, a latency block, and almost no ceremony. bombardier is the Go sibling of hey and wrk. It is easy to vendor, easy to explain, and easy to misuse if you only quote the RPS line.

This article treats bombardier as a lab instrument: when it is enough, when it is not, and how to publish a run that another engineer can repeat.

What bombardier is for

Open-loop or connection-heavy hammers against a single URL. HTTP/2 without a fight. Printed latencies. A binary you can drop into a Makefile. A bombardier HTTP benchmark is not a user-journey platform. It has no think-time DSL, no first-class threshold language like k6, and no TUI culture like oha. That narrowness is useful. Fewer knobs, fewer unique methodologies nobody can rerun.

bombardier --duration=45s --connections=256 --latencies http://10.0.0.8:8080/json

How to run it like an adult

Warm the server. Repeat three times. Publish the latency block, not only RPS. Gate errors. Separate client and server. Treat TLS and plaintext as different tests. A bombardier HTTP benchmark that skips those steps is a demo, even if the banner looks professional.

Pin the version. bombardier releases move. A lab image that floats go install at HEAD will surprise you after a holiday. Record the exact command in the report header next to the application SHA.

When bombardier disagrees with oha

Run both. Look at client CPU and protocol flags. HTTP benchmark tools are part of the measurement. If bombardier plateaus with the client saturated and oha goes further on the same box, you learned about generators, not about the framework. Write that sentence. It prevents a rewrite funded by a client limit.

When to put it down

Mixed routes, think time, gRPC, WebSocket journeys, or a PR gate expressed as code: use k6. HTTP/3 honesty: use h2load or oha’s experimental path. Constant arrival with pipe-friendly reports: vegeta. A bombardier HTTP benchmark that tries to become those tools will turn into a pile of shell that nobody owns.

Compare the three defaults in wrk vs k6 vs oha. See the wider field in HTTP load generator comparison 2026.

A report template

• Hypothesis in one sentence
• bombardier version and full command
• Protocol and TLS notes
• Median successful RPS across accepted trials
• p50 / p95 / p99 from the latency block
• Error rate and error class
• Client CPU versus server CPU

If the template is too long for the ticket, the ticket is the wrong place to hide a bombardier HTTP benchmark. Link the raw output instead of paraphrasing it.

FAQ

Is bombardier faster than wrk? Sometimes on HTTP/2. Not a reason to delete wrk2. Measure both if the ceiling matters.

Does it belong in CI? Yes as a smoke ceiling with a parsed latency gate. No as the only journey test.

License? MIT. Confirm the file in the module you vendor.

Use the hammer. Do not ask it to be a platform. That is the whole job of a bombardier HTTP benchmark.

Mistakes people make around bombardier HTTP benchmark

The first mistake is treating bombardier HTTP benchmark 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 bombardier HTTP benchmark 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 bombardier HTTP benchmark, 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 bombardier HTTP benchmark whether or not the original brief mentioned them.

Checklist before you claim bombardier HTTP benchmark

• One-sentence hypothesis that contains the phrase bombardier HTTP benchmark 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 bombardier HTTP benchmark. You are drafting. Drafts can live in a branch. They should not live in a decision memo.

Who owns bombardier HTTP benchmark 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 bombardier HTTP benchmark, 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 bombardier HTTP benchmark 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 bombardier HTTP benchmark. 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 bombardier HTTP benchmark 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 bombardier HTTP benchmark 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 bombardier HTTP benchmark. 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 bombardier HTTP benchmark, 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.