redis-benchmark

A synthetic load generator. Drives any number of pipelines of any number of clients against a Redis instance and reports throughput and latency.

Active contributors: antirez, Oran Agra, Itamar Haber.

Purpose

redis-benchmark exists primarily so reviewers and operators can answer "did this change make Redis faster or slower?" with a reproducible number. It runs canned command mixes (SET, GET, LPUSH, LRANGE, …) or a custom command, with configurable key cardinality, value size, pipeline depth, and concurrency.

Source layout

src/redis-benchmark.c (~80 KB). Like redis-cli, it is a single file with a giant main(). It uses:

• deps/hiredis/ for connection management and RESP encoding.
• src/ae.c (the same event loop the server uses) — benchmark clients are async, multiplexed over epoll/kqueue like real clients.
• src/anet.c for socket helpers.
• src/cli_common.c for shared TLS plumbing.

The structure is straightforward: parse options → fork N client objects → drive a pipeline of M commands per client → measure.

Command mix

By default redis-benchmark runs a sequence of standard tests:

PING_INLINE, PING_BULK,
SET, GET, INCR,
LPUSH, RPUSH, LPOP, RPOP, LRANGE_*,
SADD, HSET,
SPOP, ZADD, ZPOPMIN,
MSET (10 keys)

Each test uses the same options for parallelism and pipeline depth. You can restrict to one test:

./redis-benchmark -t set,get -n 1000000 -c 100 -P 16
./redis-benchmark -r 1000000 -n 1000000 -t set    # 1M random keys

For a custom command:

./redis-benchmark -n 1000000 -c 50 -P 16 -- SET key:rand:000000000000 value

The -- separates benchmark options from the literal command sent. __rand_int__ is replaced with a random number from 0..-r for keys.

Output

Each test prints throughput in requests/sec and a latency distribution. With --latency you get just the latency histogram. With --csv you get one CSV row per test for plotting.

Modes

Mode	Effect
-c <n>	Number of parallel clients.
-P <n>	Pipeline depth per client.
-r <n>	Random key range (substituted into __rand_int__).
-q	Quiet — only print the throughput summary.
-l	Loop forever.
--cluster	Cluster-aware mode: discover slots, then issue each command to the right node.
--threads <n>	Use multiple OS threads (each owns its own clients).
--tls, --cacert, --cert, --key	TLS.
--user, --pass	ACL auth.
-d <bytes>	Data size for SET/GET-style tests.
--idlemode	Open N connections and keep them idle (useful for testing connection limits).
--seed <n>	Reproducible RNG.

How the asynchronous engine works

graph LR
    Main[main] --> Setup[create N client structs]
    Setup --> Loop[aeMain]
    Loop -->|writable| Send[issue P pipelined commands]
    Loop -->|readable| Read[parse RESP replies]
    Read -->|count == N*requests| Stop[print stats]

Each client has a fixed work budget. When all clients have completed their share, aeStop drops the loop and the program prints the latency histogram + throughput.

Cluster benchmarking

--cluster first issues CLUSTER NODES to learn the slot map, then spreads the configured client count across the master nodes proportionally. Throughput numbers are aggregated. The implementation is a small block at the top of redis-benchmark.c — search for cluster_mode.

Why not wrk or memtier_benchmark?

memtier_benchmark (Redis Labs's tool) is more powerful for large-scale load testing — it supports more workload patterns and richer reporting. redis-benchmark is intentionally simpler and lives in-tree so any contributor can run it without external dependencies. It is the canonical tool for "did this PR regress performance" comparisons.

Where to start modifying

• Add a new built-in test — extend the static tests[] table in redis-benchmark.c with a name + command template.
• Add a new option — add a flag in the option parser; thread it through to the config struct.
• Tune output — search for showLatencyReport and showThroughput near the bottom of the file.