Redis 3.2.8 vs Hazelcast IMDG 3.8 Benchmark


This is a comparison between a Redis 3.2.8 cluster and a Hazelcast IMDG® 3.8 cluster.

Read our previous benchmark here >>

Get Performance

Hazelcast IMDG was up to 56% faster than Redis.

Note that near cache was disabled for Hazelcast®.

As you can see from our previous benchmark, enabling near cache makes us 5 times faster.

Set Performance

Hazelcast IMDG was up to 44% faster on puts.

Why Hazelcast IMDG is Faster Than Redis

We think Hazelcast IMDG is faster because of the following design differences:

  • Hazelcast IMDG uses highly optimized, multi-threaded clients and servers, and uses efficient asynchronous IO. Each thread owns its partitions, so there is never contention.
  • Redis is single-threaded, meaning that single instances cannot efficiently utilize available CPU resources under heavy load. Hazelcast is fully multi-threaded, with partitions owned by partition threads.
  • Jedis uses blocking sockets, while Hazelcast’s Java client uses asynchronous I/O.
  • We also have a high-performance binary protocol. Redis uses RESP, a human-readable text-based protocol.

This is the second performance test we have done where Hazelcast IMDG beats Redis. See our earlier Redis 3.0.7 vs Hazelcast IMDG 3.6 Benchmark. We have extended our performance lead over Redis with Hazelcast IMDG 3.8.

Test Environment

HP DL380p Gen9 (RHEL 7, subscribed)
2x Intel(R) Xeon(R) CPU E5-2687W v3 @ 3.10GHz
10 cores per processor (20 cores total) hyper threading enabled 40 cores
768GB 2133 MHz memory
Juniper 40GbE Switch
10x Juniper QFX-QSFP-40G- SR4 40GbE Transceiver
Juniper 10GbE Switch EX4600-40F-AFI

Cluster Topology

3 physical boxes dedicated to cluster members, 5 physical boxes for clients.

Hazelcast Redis
Members 6 (jvm’s) 96 (48 master, 48 slave)
Clients 10 (jvm’s) 10 (jvm’s)

Testing Framework

Parameter Value
Test Warmup Duration 1 minute
Test Duration (minutes) 15 minutes
Number of Threads/Client Each client drives the benchmark with 64 thread, (52 get thread, 12 set thread)
Get/Put Ratio 80:20 (Caching Use case)
Number of Unique Keys A key domain of 4,000,000 keys
Payload Strings with a random distribution of lengths between 100 bytes and length 10000 bytes
Total Cached Size 20G


Hazelcast IMDG uses a map configured with HD in memory format and async backups, by default read from backups is disabled.

Redis master Slave replication is async, by default Redis allows read from backups.

Hazelcast IMDG Config

<native-memory allocator-type="POOLED" enabled="true">
<size unit="GIGABYTES" value="100" />

<map name="mapAsync1HD*">


<max-size policy="FREE_NATIVE_MEMORY_PERCENTAGE">15</max-size>

JVM Options

hazelcast / jedis client options -Xms1G -Xmx1G
member options -Xms3G -Xmx3G

Benchmark Results

Legend for Graphs
Hazelcast (Red)
Redis (Blue)
Get (52 threads) Set (12 threads)
Throughput ops/sec


Throughput ops/sec


99 percentile latency


99 percentile latency


75 percentile latency


75 percentile latency