If you've ever wondered how fast your Redis server really is, or wanted to compare configurations, Redis comes with a handy built-in tool called redis-benchmark
that can help you simulate workloads and measure performance.
Let's walk through what redis-benchmark
is, how it works, and how to use it effectively—even if you’re just starting out.
What is redis-benchmark
?
redis-benchmark
is a utility that ships with Redis. Its job is simple: simulate multiple clients sending commands to your Redis server and show you how the server performs. It does this by sending thousands (or even millions) of requests and reporting key performance metrics like:
- Requests per second (RPS) – how many commands Redis can handle per second
- Latency – how long each request takes to process
- Throughput – how much data Redis is moving around
This tool is helpful for:
- Testing the raw speed of your Redis instance
- Comparing hardware or server configurations
- Spotting bottlenecks in your Redis setup
- Planning capacity for production systems
Why Should You Benchmark Redis?
Redis is known for being lightning-fast, but performance can vary based on your system’s CPU, memory, network, and Redis configuration. For example:
- Are you using
appendonly
or persistence? - Are you running Redis on a virtual machine or bare metal?
- Are you sharing the server with other services?
redis-benchmark
helps you answer questions like:
- “How many GET/SET operations per second can I expect?”
- “What happens if 50 clients hit my Redis at the same time?”
- “Is Redis the bottleneck or is it something else?”
Basic Usage
To get started, open your terminal and run:
redis-benchmark
This sends 100,000 requests using 50 parallel clients by default, and tests common commands like SET
, GET
, INCR
, LPUSH
, LPOP
, etc.
Here’s an example output snippet:
====== SET ======
100000 requests completed in 1.25 seconds
50 parallel clients
3 bytes payload
keep alive: 1
99.99% <= 1 milliseconds
79617.03 requests per second
This means Redis handled nearly 80,000 SET commands per second, and most completed in under 1 millisecond.
Customizing the Benchmark
You can tweak several parameters:
-
-c
: Number of concurrent clients (default is 50) -
-n
: Total number of requests (default is 100000) -
-d
: Data size of SET/GET payload in bytes -
-t
: Specific tests to run (e.g.,SET
,GET
,INCR
)
For example, to test 10,000 GET requests using 100 clients:
redis-benchmark -t GET -n 10000 -c 100
To test SET with 1KB of data per request:
redis-benchmark -t SET -d 1024
Interpreting the Results
Here are a few things to pay attention to:
- Requests per second: The higher, the better. This gives a rough measure of throughput.
- Latency: Measured in milliseconds. Lower latency means faster response times.
- Distribution: The tool also shows how many requests fall under a certain latency threshold, which helps you understand performance consistency.
When to Use It
Use redis-benchmark
:
- Before going to production, to estimate capacity
- After making config changes, to see their impact
- When moving to new hardware or cloud providers
- To compare different Redis versions or setups
Wrapping up
Benchmarking might sound like something only advanced engineers do, but tools like redis-benchmark
make it accessible even to beginners. With just a few commands, you can get a clearer picture of how your Redis server behaves under pressure.
Understanding these results can help you make informed decisions about scaling, optimization, and system design.
Redis is fast by design. But knowing how fast, and under what conditions, is what makes you a better developer or engineer.
If you're a software developer who enjoys exploring different technologies and techniques like this one, check out LiveAPI. It’s a super-convenient tool that lets you generate interactive API docs instantly.
LiveAPI helps you discover, understand and use APIs in large tech infrastructures with ease!
So, if you’re working with a codebase that lacks documentation, just use LiveAPI to generate it and save time!
You can instantly try it out here! 🚀
this is extremely impressive, especially for someone just starting out with Redis
any thoughts on common mistakes people run into when reading benchmark results