Redis vs Hazelcast: Cluster Performance Benchmark Reveals Surprising Scalability Insights

Laboratory Configuration

Tests were run on a cluster of HP ProLiant DL380 servers, each with dual Xeon E5-2687W v3 CPUs (10 cores, hyper‑threaded), 768 GB RAM, RHEL 7, and a 40 GbE SolarFlare NIC for point‑to‑point communication.

Test Setup

Redis 3.0.7 (client Jedis 2.8.0) was compared with Hazelcast 3.6.1 using the RadarGun benchmark tool (with a custom Redis plugin). Four test scenarios varied client count and processes per client (1‑1, 4‑8, 4‑32, 4‑64).

Throughput Results

Redis showed very high request rates with few clients but degraded sharply under high concurrency, while Hazelcast performed modestly at low load and scaled better as client threads increased. Detailed request‑per‑second numbers:

Scenario 1: Hazelcast 13,954 req/s vs Redis 50,634 req/s

Scenario 2: Hazelcast 365,792 req/s vs Redis 645,976 req/s

Scenario 3: Hazelcast 872,773 req/s vs Redis 702,671 req/s

Scenario 4: Hazelcast 1,166,204 req/s vs Redis 722,531 req/s

Latency

Latency followed a similar pattern. Redis had lower latency at low load (≈19 µs vs 70 µs) but latency grew exponentially with more threads, reaching 640 µs at scenario 4, whereas Hazelcast latency increased more linearly (≈218 µs).

Conclusion

Redis is an excellent choice for workloads with few users and low contention, but its performance deteriorates under heavy concurrent load. Hazelcast, while slower at small scale, scales more predictably and outperforms Redis in high‑load cluster environments. Developers and architects should benchmark both solutions against their specific use cases before deciding.