Measure Redis Throughput Safely with redis-benchmark

You will finish with a repeatable Redis throughput check, a record of the workload that produced it, and a way to avoid writing benchmark data into the wrong database. The examples use redis-benchmark 7.0.15 from Ubuntu package redis-tools 5:7.0.15-1ubuntu0.24.04.4.

Allow about fifteen minutes for a small test, plus time to repeat it on the real host. You need redis-benchmark installed and a reachable Redis server. A running Redis instance is a prerequisite; this guide does not start, stop or reconfigure a production service.

1. Check the installed client

Confirm the executable and its version before comparing results. This is an ordinary read-only check and does not need elevated privileges:

$ command -v redis-benchmark
/usr/bin/redis-benchmark
$ redis-benchmark --version
redis-benchmark 7.0.15
$ dpkg-query -W -f='${Package} ${Version}\n' redis-tools
redis-tools 5:7.0.15-1ubuntu0.24.04.4

Option names and defaults can vary between releases. The installed manpage is the local contract, while --help shows the newer options available in this package. If you are comparing two hosts, record the benchmark client version on both.

Checkpoint: you know which binary will generate the load and which package supplied it.

2. Prove that the target is the one you intend to test

Redis-benchmark defaults to host 127.0.0.1 and port 6379. Do not rely on those defaults when more than one Redis instance exists. Check the endpoint with redis-cli or another trusted client before sending a workload:

$ redis-cli -h REDIS_HOST -p REDIS_PORT ping
PONG

Replace REDIS_HOST and REDIS_PORT with the actual values. A Unix socket can be selected with -s SOCKET_PATH instead of -h and -p. Authentication uses -a PASSWORD; the 7.0.15 client also supports --user USERNAME for ACL authentication. Passwords placed directly in a command can leak through shell history or process inspection, so prefer a controlled shell environment and a maintenance procedure approved for your host.

A failed PING is a stopping point. Check the address, port, firewall and Redis logs. Increasing the client count will not repair a connection problem.

3. Start with a read-only command workload

A plain redis-benchmark runs its standard collection of tests, including operations that write keys. That may alter a live dataset. Begin with PING so the first measurement does not create application keys:

$ redis-benchmark -h REDIS_HOST -p REDIS_PORT -t ping -n 10000 -c 10 -q
PING_INLINE: 00000.00 requests per second, p50=0.000 msec
PING_MBULK: 00000.00 requests per second, p50=0.000 msec

The numbers will depend on the machine and network. The two test names and the exact formatting are illustrative: keep the output from your run, not these sample values. -n is the total request count and -c is the number of parallel connections. -q keeps the output to query-per-second and latency summaries.

Do not treat a PING result as an application benchmark. It measures a small command and the complete path between client and server. It is useful as a baseline for connectivity and round-trip cost.

4. Match the workload to the application

Use -t with a comma-separated list of the test names printed by the program. For example, this measures SET and GET with a small request count on a deliberately named test endpoint:

$ redis-benchmark -h REDIS_HOST -p REDIS_PORT -t set,get -n 10000 -c 20 -d 256 -q

This command writes benchmark keys. Run it only against an isolated database or a host where that data is acceptable. The -d value controls the SET and GET value size in bytes; this installed client defaults to 3 bytes, while the local manpage for older builds may show a different default. Choose a value that resembles the application rather than accepting a convenient number.

To avoid collisions with existing keys, -r KEYSPACE_LENGTH makes supported operations use a changing key or member suffix. It does not make writes harmless, and a large keyspace can leave many keys behind. Record the database number selected with --dbnum NUMBER or the manpage's -dbnum form, and clean up only keys created by your test. Never run a broad delete command on a shared database as a guessed cleanup step.

Checkpoint: write down the host, database, command list, payload size, request count, client count and whether the test used pipelining. Without those details, later numbers are difficult to compare.

5. Decide whether concurrency or pipelining is realistic

With the default -P 1, each connection has one request in flight at a time. Increase the pipeline size only when the real client batches requests in a similar way:

$ redis-benchmark -h REDIS_HOST -p REDIS_PORT -t ping -n 100000 -c 50 -P 8 -q

Pipelining can raise throughput by reducing round trips, so its result is not directly comparable with a non-pipelined run. Likewise, -c 50 is a workload choice, not a measurement of the server's maximum capacity. Hold every option constant when comparing a change, then run several repetitions rather than selecting the best result.

For a baseline, keep the server workload stable. Background saves, persistence activity, monitoring commands, network traffic and CPU frequency changes can all move the result. The Redis documentation recommends comparing like with like and warns that a benchmark can be affected by concurrent server activity.

6. Capture machine-readable output

Use --csv when a script or spreadsheet needs the latency fields. This example sends a small PING-only run to standard output:

$ redis-benchmark -h REDIS_HOST -p REDIS_PORT -t ping -n 1000 -c 2 --csv
"test","rps","avg_latency_ms","min_latency_ms","p50_latency_ms","p95_latency_ms","p99_latency_ms","max_latency_ms"
"PING_INLINE","...","...","...","...","...","...","..."
"PING_MBULK","...","...","...","...","...","...","..."

The ellipses mark values that are specific to the run, not literal output to paste into a parser. Save the complete command and CSV together. If a command fails or returns server errors, investigate before treating a high requests-per-second value as useful. In the 7.0.15 help, -t is ignored when you supply a specific command after the options, so choose one style deliberately.

7. Stop safely and clean up

Redis-benchmark exits after -n requests. A command with -l loops forever, and -I opens idle connections, so use them only when you have a clear stop condition. Press Ctrl-C to stop an interactive run. If you launched the benchmark from a service manager or script, stop that wrapper through its normal control path.

Tests using SET, INCR, list, set or sorted-set commands can leave data behind. Before a write test, choose an isolated Redis instance or a dedicated database and agree how its contents will be discarded. Database-wide commands such as FLUSHDB are destructive and affect every key in the selected database, so do not use them as automatic cleanup on a shared service. If you need to remove test data, use an application-aware key list or restore the disposable instance instead.