redis-benchmark: how to use it and read its numbers

redis-benchmark is the benchmark utility that ships with Redis: it opens a number of client connections (50 by default), sends a fixed number of commands (100,000 by default) and reports requests per second and latency for each test. Run redis-benchmark -q -n 100000 against a running server, narrow it to the commands you care about with -t, and read the result as the speed of one Redis instance under synthetic commands. Your application adds its own network path, client library and command mix, so expect its figures to differ.

We ran it on 31 October 2026 on an Apple M1 Max laptop, Redis 7.2.6 server and client on one machine over loopback, persistence off. Each row is one run of 100,000 requests, with requests per second rounded to the nearest thousand; p50 is as printed.

How do you run redis-benchmark?

Point the tool at a running server with -h and -p; with no options it runs its default test suite against 127.0.0.1:6379. Add -t to pick tests and -q to print one line per test.

redis-benchmark -h 10.0.0.12 -p 6379 -c 50 -n 100000 \
  -t set,get -q

The official Redis benchmark page and the --help output of version 7.2.6 list these options, among others (checked on 31 October 2026):

• -c parallel connections (default 50) and -n total requests (default 100,000).
• -d size of SET and GET values in bytes (default 3).
• -P commands per pipeline (default 1, no pipelining).
• -t a comma-separated list of tests; -q quiet output; --csv CSV output.
• -r random keys from a key space of that size. Without it, every command uses the same key.
• -k 1 keeps connections alive (the default), -k 0 reconnects.
• --threads turns on multi-thread mode; --cluster turns on cluster mode, where -c must be at least the number of nodes.

How do you read redis-benchmark output?

With -q you get one line per test: requests per second and the median latency. Without it, each test prints its settings, a latency distribution by percentile and a summary with the average, minimum, p50, p95, p99 and maximum latency.

The header also prints the server’s save and appendonly settings, which tell you whether persistence was part of the test. Our full GET run read 119,617 requests per second, an average of 0.352 ms, p95 0.559 ms, p99 0.623 ms and a maximum of 0.759 ms. A request that makes many Redis calls is likelier to meet a slow one, so read p99 too; see our tail latency article.

--csv prints the summary as one row per test. Repeat runs before you trust a small difference: two runs of the same SET test gave us about 113,000 and 125,000 requests per second.

Why does pipelining change the numbers so much?

Without -P, each client waits for a reply before sending its next command, so every command pays a full round trip. With -P 16 each client sends 16 at once, and in our run SET rose from about 113,000 to 1,010,000 requests per second and GET from 118,000 to 1,190,000.

The official page calls pipelining realistic, since many Redis applications use it, and advises a pipeline size close to the average your application can use. Our median latency rose at the same time, to 0.711 and 0.583 ms.

What happens when you add more clients?

Once the bottleneck is saturated, more clients only add waiting. On one laptop that can be the server or the single-threaded benchmark client.

Going from 50 to 200 clients left throughput almost flat (about 117,000 SET and 123,000 GET requests per second) while the median latency roughly tripled, to 1.135 and 1.071 ms. That is Little’s law at work. Each client keeps at most one command in flight, so -c fixes how many are in the system, and if throughput cannot grow, the time each spends there must. In our full GET run, 50 clients ÷ 119,617 requests per second gives 0.42 ms per client loop, a little above the measured average of 0.352 ms. With 200 clients the same calculation gives 1.63 ms.

This also makes the tool’s load a closed workload: when Redis stalls, the clients wait, so the commands your application would have sent meanwhile never appear. Neither the official page nor --help lists a fixed-rate option, so read its percentiles with coordinated omission in mind.

How do you benchmark your own command or a Lua script?

Put the command after the options. The tool then runs only that command and ignores -t.

redis-benchmark -n 100000 -q \
  script load "redis.call('set','foo','bar')"
redis-benchmark -r 10000 -n 10000 \
  eval 'return redis.call("ping")' 0

The first line is the official page’s example, which ran at about 106,000 requests per second on our laptop. SCRIPT LOAD only loads the script, so use eval, as in the second line from --help, to time running one. With -r, the help says __rand_int__ in an argument becomes a random 12-digit number in that range, and in cluster mode the key must contain a {tag} to reach the right node.

Why does your application see different numbers?

Your application measures its whole path to Redis: network, client library, serialization and its own command mix. The official page lists pitfalls to check before you compare.

• A loop of synchronous commands mostly measures the network and the client library.
• With client and server on one box, the CPU limits the benchmark. Unix domain sockets can reach around 50% more throughput than TCP loopback, on Linux for instance.
• 4 KB strings at 100,000 queries per second need about 3.2 Gbit/s, more than a 1 Gbit/s link carries.
• To compare Redis with a transactional database, turn on AOF and choose a suitable fsync policy.
• Laptops vary their CPU frequency, which hurts repeatability.
• INFO at intervals is probably fine during a run, while MONITOR slows Redis significantly. Our publisher’s roundup of Redis monitoring tools covers the metrics worth watching.

Are these laptop numbers Redis’s real capacity?

No. They show one laptop talking to itself, with no network, 3-byte values in most runs, no persistence and one run per row.

The table shows how each option moves the figures. Capacity depends on your server, network, value sizes and persistence settings.

When is redis-benchmark the wrong tool?

When you want to know what users feel. It sends synthetic commands to Redis alone, while a page’s response time also includes the application code and its other calls.

For that, load the application or API that uses Redis and watch Redis while the test runs. LoadFocus, which publishes this site, works at that layer: it runs JMeter test plans and k6 scripts from 25 cloud regions against your web app or API. It does not run redis-benchmark.

For more control over Redis traffic, the memtier_benchmark repository lists multi-threaded clients, a read:write ratio, random or sequential key patterns, Redis Cluster and TLS (checked on 31 October 2026).

FAQ

Is redis-benchmark designed to make Redis look fast? No. The official Redis page calls that a common misconception: by default the tool keeps at most one query pending per connection, with no pipelining, and a client that pipelines can generate more throughput.

How do you fill a Redis database with redis-benchmark? Run only the SET test with random keys, as the tool’s help shows: -t set -n 1000000 -r 100000000 fills about one million keys. Random keys can repeat, so the final count ends a little lower.

Can LoadFocus run redis-benchmark? No. LoadFocus does not run redis-benchmark. Its JMeter test plans and k6 scripts are aimed at the web app or API in front of Redis.

Related reading

• Little’s law in load testing: size and check your tests
• Tail latency: what it is and how to measure it
• Coordinated omission: what it is and how to avoid it
• Open vs closed workload model: which one should you use?
• HTTP benchmarking tools: wrk, hey, oha, ab and more
• pgbench: how to benchmark and load test PostgreSQL
• How to use sysbench for CPU, disk and MySQL benchmarks
• YCSB: workloads A-F, how to run it and its limits

The technical claims in this article have not been independently reviewed.