Best HTTP Load Testing CLI Tools
Compare wrk, vegeta, k6 and hey for HTTP load testing: requests per second, latency percentiles, constant-rate attacks and scripting.
Updated
short verdict
Use wrk when you want the highest request rate from one machine and a quick latency distribution. Use vegeta when you need a fixed request rate and composable reports, and k6 when the test is a scripted scenario that runs in CI. hey is the simplest one-liner, and ali adds live charts in the terminal.
HTTP load testing tools differ mainly in how they generate load and what they report. Some push as many requests as the connections allow, some hold a constant rate, and some run scripted user scenarios. They also differ in output: a text summary, piped binary results, exported files, or live terminal charts. The five tools below cover requests per second and latency measurement from the command line.
this page is for
- Developers benchmarking a web server or API for requests per second and latency
- Engineers who need a constant request rate rather than maximum throughput
- Teams adding performance thresholds to a CI pipeline
- SREs who want to watch latency percentiles while a test runs
A C benchmarking tool that uses threads plus epoll or kqueue to push high load from one multi-core machine, with latency distribution and requests per second in the output.
best for
- Maximum-throughput benchmarks of a single endpoint
- Quick latency distribution checks from one host
strengths
- One command sets threads, connections and duration: wrk -t12 -c400 -d30s URL
- Reports latency distribution, standard deviation, requests per second and transfer rate
- Optional LuaJIT scripts change methods, paths, headers and bodies, and can process responses
- Event notification through epoll and kqueue, so one multi-core machine can generate heavy load
weaknesses
- Load is set by threads and connections; a fixed request rate option is not documented
- Custom scenarios require writing Lua
- Output is a text summary, with no built-in plots or export formats
A Go CLI and library that attacks at a constant request rate, avoids Coordinated Omission, and splits attack and reporting into pipeable commands.
best for
- Fixed-rate tests where latency under a known load matters
- Pipelines that save results and analyze them later
strengths
- Constant rate per time unit, for a set duration or indefinitely
- Targets come from stdin or files in HTTP or JSON format, with custom headers, bodies and authentication
- Separate encode, plot and report commands give text, JSON, histograms with custom buckets, or HTML plots
- Supports HTTP/2, persistent connections, TLS options and DNS caching
weaknesses
- Getting a report takes at least two piped commands (attack, then report)
- Uses a target file or stdin format instead of a single URL flag
- Installed through a package manager or Go; the project lists Homebrew, pacman and pkg
A small Go tool where -n, -c and -z set request count, concurrency and duration, with a summary and optional CSV export.
best for
- Quick manual checks of a web service
- Capacity planning with simple concurrency steps
strengths
- Flags -n for request count, -c for concurrency and -z for duration
- Supports HTTP/1.1 and HTTP/2, custom headers, authentication, request bodies and proxies
- Rate limiting option and timeouts are configurable
- CSV export for analysis in other tools
weaknesses
- No scripting layer for multi-step scenarios
- No live charts or plotting; output is a summary or CSV
- No documented threshold or pass/fail mechanism for CI
A Go load generator with a JavaScript test API, thresholds and scenario executors, for tests kept in version control and run in CI.
best for
- Scripted scenarios with assertions in CI
- Tests that also cover WebSockets or gRPC
strengths
- Tests are JavaScript files, so logic can be shared, modularized and versioned
- Thresholds act as performance assertions; executors cover open and closed models and constant RPS
- Supports HTTP, WebSockets and gRPC in one tool
- Exports metrics to monitoring systems; can run distributed on Kubernetes or with Grafana Cloud
weaknesses
- You must write a script even for a one-URL benchmark
- AGPL-3.0 license, which matters for some organizations
- Much larger scope than a plain RPS benchmark, with more concepts to learn
A load tester that plots latency, percentiles and throughput in an interactive terminal UI while the test runs.
best for
- Watching latency percentiles change during a test
- Exploratory tuning of an API under load
strengths
- Live charts of latency over time and the 50th, 90th, 95th and 99th percentiles
- Mouse zoom and navigation in charts; redraw interval is configurable
- Flags for rate, duration, method, headers and body; body can be read from a file
- Duration 0 runs an infinite test; supports HTTP/2, keep-alive, TLS settings and custom DNS resolvers
weaknesses
- Built around an interactive terminal UI; CI use is not documented by the project
- Exports results to files, but no plotting or reporting pipeline like vegeta
- No scripting for multi-step scenarios
How to choose
The deciding factor is usually how you want load applied and where the results go.
- Highest throughput from one machine: wrk, with threads and connections set by -t and -c.
- Constant request rate and reusable results: vegeta, with piped attack, report and plot commands.
- Scripted scenarios and CI thresholds: k6, using JavaScript tests with pass/fail thresholds.
- Simplest one-line run with CSV output: hey, using -n, -c and -z.
- Live latency percentile charts while testing: ali, with its interactive terminal UI.
When not to use these
- You need to load test non-HTTP protocols other than WebSockets or gRPC; none of these tools document support for them.
- You need browser-level performance numbers from real page loads; these tools measure requests and responses, not rendering.
FAQ
- Which tool gives the highest requests per second?
- wrk is built for high load from a single multi-core machine, using multiple threads with epoll or kqueue. Results depend on your hardware and target, and the project gives no comparison figures against the other tools.
- Which tool holds a constant request rate?
- vegeta attacks at a constant rate per time unit and avoids Coordinated Omission. k6 also offers constant RPS executors, and ali lets you set the request rate with a flag.
- Can I script complex requests?
- Yes, with wrk through optional LuaJIT scripts, or with k6 through JavaScript tests. vegeta takes per-request headers and bodies from its target files, and hey and ali take them as flags.
- Which tool is best for watching results live?
- ali draws latency, percentile and throughput charts in the terminal as the test runs, with mouse zoom. The others print a summary or write results for later analysis.