Redis performance benchmarking is one of the crucial tasks which we need to consider before drafting a solution that will help to understand how redis write and read will be.
So there is a default utility that comes along with redis package called "redis-benchmark" to measure the performance of Redis.
So let's deep dive into this utility and understand how this utility will help you understand redis performance.
Availability of redis-benchmark
To check the availability of redis-benchmark on your server run the below commands.
[root@siddhesh ~]# which redis-benchmark
/usr/bin/redis-benchmark
[root@siddhesh ~]# So redis-benchmark binary is available on our local server.
As I mentioned earlier by using this utility we can measure the performance of redis So let's run redis-benchmark without any additional flag to see what it does exactly to measure the performance.
So by default redis-benchmark with no additional flag mentioned in the command line, runs a total of 100000(1 Lakh) requests with 50 parallel clients and 3 bytes of payload.
Let's understand what it means.
1,00,000 Requests: redis-benchmark generates 100000 client requests to the localhost redis server using different data types & actions such as PING, SET, GET, INCR, LPUSH, RPUSH, LPOP, RPOP, SADD, HSET, SPOP etc 50 parallel clients: 50 client connections at a time to complete 100,000 requests. 3 bytes of payload: payload is nothing but the size of data to be used per connection to upload the data.
[root@siddhesh ~]# redis-benchmark
====== PING_INLINE ======
100000 requests completed in 1.06 seconds
50 parallel clients
3 bytes payload
keep alive: 1
99.97% <= 1 milliseconds
100.00% <= 1 milliseconds
94339.62 requests per second
...
OutPut Truncated
...
93.53% <= 1 milliseconds
99.98% <= 2 milliseconds
100.00% <= 2 milliseconds
71839.09 requests per second
[root@siddhesh ~]#
redis-benchmark quiet mode
default redis-benchmark command without any options generates lots of unwanted output which may not be useful to consider while doing benchmarking. So there is an option to perform this benchmark in a quiet mode which generates very less but useful output to consider the performance throughput.
[root@siddhesh ~]# redis-benchmark -q
PING_INLINE: 94161.95 requests per second
PING_BULK: 93896.71 requests per second
SET: 94786.73 requests per second
GET: 93808.63 requests per second
INCR: 93545.37 requests per second
LPUSH: 94073.38 requests per second
RPUSH: 93632.96 requests per second
LPOP: 93984.96 requests per second
RPOP: 94876.66 requests per second
SADD: 93370.68 requests per second
SPOP: 95969.28 requests per second
LPUSH (needed to benchmark LRANGE): 97465.88 requests per second
LRANGE_100 (first 100 elements): 36231.88 requests per second
LRANGE_300 (first 300 elements): 15062.51 requests per second
LRANGE_500 (first 450 elements): 9825.11 requests per second
LRANGE_600 (first 600 elements): 7505.82 requests per second
MSET (10 keys): 66934.41 requests per second
[root@siddhesh ~]# In the output, we can clearly see the average number of requests per second that the server handles with a different types of data operations.
Limit redis benchmark on specific data type operations.
In your case you might find running redis benchmark on all data types is not that useful. So you can limit this specifically to the data type which is being used in your project.
In the below example, we'll consider only GET & SET operations of string data type.
[root@siddhesh ~]# redis-benchmark -q -t SET,GET
SET: 85034.02 requests per second
GET: 95693.78 requests per second
[root@siddhesh ~]# So -t flag we can use to define a list of test on various data type.
Number of parallel connections
The default parallel connections limit of redis-benchmark is 50 we can increase this with flag -c In the below example, we'll run redis benchmark with 1000 concurrent connections.
[root@siddhesh ~]# redis-benchmark -q -t SET,GET -c 1000
SET: 59844.41 requests per second
GET: 59737.16 requests per second
[root@siddhesh ~]# As you can see here as we increase the total number concurrent connections from 50 to 1000 there is an impact on the throughput.
Number of requests
The default number of requests is 100000 which we can increase to match the volume which we are expecting in production. In the below example, we'll run redis benchmark with a total 300000 of requests with 1000 concurrent connections.
[root@siddhesh ~]# redis-benchmark -q -t SET,GET -c 1000 -n 300000
SET: 58139.54 requests per second
GET: 58548.01 requests per second
[root@siddhesh ~]# Size of payload
The default payload size is 3 bytes which we can increase using -d In the below example, we'll run redis benchmark with a total 300000 of requests with 1000 concurrent connections and 1KB of payload.
[root@siddhesh ~]# redis-benchmark -q -t SET,GET -c 1000 -n 300000 -d 1000
SET: 53802.01 requests per second
GET: 55157.20 requests per second
[root@siddhesh ~]# In the output, you can observe a significant decrease in performance after increasing a payload size by just 1KB.
Redis Benchmark using pipeline
In redis pipeline (-P) is a method that we use to run multiple commands at the same time without waiting for the response of every individual command. In the below example, we'll use the same workload as mentioned in the above example with 10 commands at the same time.
[root@siddhesh ~]# redis-benchmark -q -t SET,GET -c 1000 -n 300000 -d 1000 -P 10
SET: 310880.84 requests per second
GET: 334448.16 requests per second
[root@siddhesh ~]# In the output above you can see a significant amount of changes in requests number per second when we enabled the pipeline.
Comments