wrk2: Constant Throughput Load (-R)
wrk2 is a wrk fork that holds a constant request rate with -R (requests/sec) and corrects coordinated omission, so its latency numbers are honest under load.
Plain wrk measures how fast a closed loop goes, which hides queueing delay. wrk2 instead paces requests at a fixed -R and reports the true latency a client at that rate would see, which is what you actually want to gate on.
What it does
wrk2 keeps the same -t/-c/-d flags but adds a mandatory -R/--rate target throughput. It schedules requests to hit that rate and accounts for coordinated omission, so p99 reflects real tail latency at the offered load rather than an optimistic loopback number.
Common usage
# hold 2000 req/s for 60s across 4 threads / 100 connections
wrk2 -t4 -c100 -d60s -R2000 --latency http://localhost:8080/
# a lower rate to check latency SLO at expected traffic
wrk2 -t2 -c50 -d30s -R500 --latency http://localhost:8080/apiOptions
| Flag | What it does |
|---|---|
| -R, --rate N | Target requests per second (REQUIRED in wrk2) |
| -t, --threads N | Number of threads |
| -c, --connections N | Connections kept open |
| -d, --duration T | Duration, e.g. 60s |
| --latency | Print the corrected latency distribution |
In CI
Set -R to the traffic level your SLO is written for, then fail the build if the reported 99% latency exceeds budget. Because wrk2 corrects coordinated omission, a p99 that jumps under load is a real regression, not a measurement artifact.
Common errors in CI
If you omit -R, wrk2 either errors or behaves like plain wrk with a wildly optimistic latency; always pass -R. A reported rate far below the requested -R means the server cannot keep up (the actual Requests/sec line is below the target) - that is the signal to fail. wrk2: command not found means build it from source or use a container image, since distro packages usually ship plain wrk, not wrk2.