Performance benchmarks - redis mget vs pipeline

This post was originally published at distributedstack.

Redis provides a benchmarking tool called redis-benchmark for testing the performance of common redis commands. The benchmarks in this blog are run on below configuration.

Model - MacBook Air 2019
Processor - 1.6 GHz Dual-Core Intel Core i5
Memory - 8 GB 2133 MHz LPDDR3
Client - redis-benchmark
Server - localhost:6379

Both client and server are running on the same machine
redis-benchmark runs the tests over 100000 commands by default. You can tweak the numbers as required.

If you haven’t already, do checkout this article for more details on redis-benchmark tool.

Below benchmark runs 1000 commands in each pipeline over all the available tests.

$redis-benchmark -q -P 1000

PING_INLINE: 200803.22 requests per second
PING_BULK: 401606.44 requests per second
SET: 236406.61 requests per second
GET: 277008.31 requests per second
INCR: 229885.06 requests per second
LPUSH: 184501.84 requests per second
RPUSH: 220750.55 requests per second
LPOP: 183150.19 requests per second
RPOP: 223713.64 requests per second
SADD: 224719.11 requests per second
HSET: 172117.05 requests per second
SPOP: 335570.47 requests per second
LPUSH (needed to benchmark LRANGE): 186219.73 requests per second
LRANGE_100 (first 100 elements): 18278.19 requests per second
LRANGE_300 (first 300 elements): 6242.20 requests per second
LRANGE_500 (first 450 elements): 4006.73 requests per second
LRANGE_600 (first 600 elements): 2906.55 requests per second
MSET (10 keys): 29299.74 requests per second

So, we could do ~277k reqs/sec with redis get command in pipeline.

Let’s set some keys to benchmark redis mget

set hash1_key1 "The golden rule of a useful benchmark is not to compare apples to oranges"
set hash2_key2 "The golden rule of a useful benchmark is not to compare apples to oranges"
set hash3_key3 "The golden rule of a useful benchmark is not to compare apples to oranges"
$redis-benchmark mget hash1_key1 hash2_key2 hash3_key3 ... (1000 keys)

  100000 requests completed in 113.54 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

0.00% <= 1 milliseconds
0.06% <= 2 milliseconds
15.38% <= 44 milliseconds
20.01% <= 45 milliseconds
25.82% <= 46 milliseconds
32.60% <= 47 milliseconds
40.24% <= 48 milliseconds
48.40% <= 49 milliseconds
56.21% <= 50 milliseconds
63.03% <= 51 milliseconds
68.34% <= 52 milliseconds
72.26% <= 53 milliseconds
75.10% <= 54 milliseconds
90.14% <= 78 milliseconds
95.77% <= 83 milliseconds
99.99% <= 234 milliseconds
100.00% <= 235 milliseconds
100.00% <= 236 milliseconds
100.00% <= 237 milliseconds
100.00% <= 241 milliseconds
880.72 requests per second

So, we were able to fetch 880*1000 = 880k keys/sec via mget compared to 277k keys/sec with get in pipeline.