wrk: Usage, Options & Common CI Errors
wrk generates significant HTTP load from a single multithreaded process.
wrk pushes far more throughput than ab thanks to multithreading and epoll. The trade-offs: latency stats can mislead under coordinated omission, and the file-descriptor limit bites at high concurrency.
What it does
wrk runs a multithreaded HTTP benchmark, holding -c open connections across -t threads for -d seconds and reporting latency distribution and requests/sec. Lua scripts (-s) customize requests and aggregate custom metrics.
Common usage
wrk -t4 -c100 -d30s https://example.com/
wrk -t8 -c400 -d1m --latency https://example.com/
wrk -t2 -c50 -d10s -s post.lua https://api/x
wrk -t4 -c100 -d30s -H "Authorization: Bearer ${TOKEN}" https://api/xOptions
| Flag | What it does |
|---|---|
| -t <N> | Number of threads |
| -c <N> | Total open connections |
| -d <t> | Test duration (e.g. 30s, 1m) |
| --latency | Print the full latency percentile distribution |
| -s <file.lua> | Load a Lua script for requests/reporting |
| --timeout <t> | Socket/request timeout |
Common errors in CI
"unable to connect to ... Connection refused" - the target is down or not ready. "socket: Too many open files" appears when -c exceeds the ulimit; raise it (ulimit -n 65535) or lower -c. Setting -c lower than -t errors with "number of connections must be >= threads". wrk reports "Socket errors: connect N, read N, timeout N" instead of failing the process, so a clean exit can still hide errors - assert on that line in CI. wrk does not follow redirects.