redis-benchmark: Usage, Options & Common CI Errors
redis-benchmark measures Redis throughput by hammering it with commands.
redis-benchmark drives performance gates in CI. The dangerous default is that it writes test keys into the live database, so never point it at a database you care about without scoping the tests.
What it does
redis-benchmark issues a configurable number of operations across many parallel clients and reports requests per second per command type. It is the built-in load generator shipped with Redis.
Common usage
redis-benchmark -h 127.0.0.1 -p 6379 -n 100000 -c 50 -q
redis-benchmark -h 127.0.0.1 -a secret -t set,get -n 100000 -q
redis-benchmark -h 127.0.0.1 -t set -n 100000 -P 16 -q # pipelined
redis-benchmark -h 127.0.0.1 -t get -n 10000 -r 100000 -q # random keysOptions
| Flag | What it does |
|---|---|
| -n <N> | Total number of requests |
| -c <N> | Number of parallel connections |
| -t <tests> | Only run named tests (set,get,...) |
| -P <N> | Pipeline N commands per round-trip |
| -q | Quiet: just the requests/second summary |
| -r <N> | Use random keys from a space of N |
Common errors in CI
redis-benchmark writes real keys (e.g. key:rand:* and the SET payload) into the target database, so running it against a shared or to-be-asserted dataset pollutes it - point it at a throwaway database/container. NOAUTH appears on a protected server unless you pass -a. Results are CPU- and network-bound on shared runners, so treat them as relative trend signals, not absolute SLAs, and pin -n/-c for comparability.