wrk HTTP Benchmark

wrk is a high-performance HTTP benchmarking tool capable of generating significant load from a single multi-core machine. It combines a multithreaded design with scalable event notification (epoll, kqueue) to drive far more concurrent connections than older tools like ApacheBench, making it a common choice for stress-testing web servers and APIs. Its small footprint and high output per machine make it popular for quick capacity probing during development and tuning.

What It Measures

wrk reports requests per second (throughput), data transfer rate, and a latency distribution including average, standard deviation, maximum, and configurable percentiles such as p50, p90, and p99. By holding many connections open and pipelining requests, it measures how a server behaves under sustained concurrent load rather than one request at a time, which surfaces queueing and contention that single-request tests never reveal.

Methodology

A run specifies the number of threads, the number of open connections, and the test duration, for example twelve threads, four hundred connections, for thirty seconds. wrk distributes connections across threads, issues requests as fast as the server responds, and aggregates timings. Its embedded LuaJIT scripting lets users customize request generation, headers, POST bodies, and dynamic URLs, and compute custom statistics in setup, request, and done hooks. The companion tool wrk2 adds a constant request-rate mode that corrects coordinated-omission bias, producing far more honest tail-latency numbers under saturation.

How to Interpret Results

Higher requests per second is better, but read latency percentiles carefully: a high average throughput with a long p99 tail means some users experience poor responsiveness even when the average looks fine. Always ensure the load generator itself is not the bottleneck; if client CPU saturates, results understate the server, so monitor the generator. For accurate tail-latency numbers under a target rate, prefer wrk2's fixed-rate mode, since open-loop measurement avoids the optimism of closed-loop tools that only send a new request after the previous slow one returns. Run from a network position close to production conditions.

Limitations

wrk measures HTTP throughput and latency for relatively simple request patterns; it is not a full scenario or session simulator like JMeter, k6, or Gatling. Standard wrk suffers from coordinated omission, understating tail latency under saturation, which wrk2 addresses but at the cost of a fixed-rate model that must be configured carefully. It does not model think time, user journeys, authentication flows, or assertions. Use wrk for raw endpoint stress tests and capacity probing, and a scenario tool when you need realistic multi-step user flows.