We recently conducted a second performance benchmark between Redis 3.2.8 cluster and a Hazelcast IMDG 3.8 cluster, following on from an earlier benchmark we did last year against 3.0.7. Check out the benchmark.
In summary, when comparing get performance, Hazelcast IMDG was up to 56% faster than Redis. For set performance, the Hazelcast IMDG was up to 44% faster than Redis. We extended our lead from last year where we were 32% faster on gets.
This was with Near Cache disabled for Hazelcast, so it was an over the network for each request, Apples to Apples comparison. Redis does not have the near cache concept. If your use case is Ok with eventually consistent near cache data held on the client side of the network, then the usual Pareto distribution and a mostly read workload will give a 5x performance advantage over Redis.
Either way we are faster, and getting even faster.
You may ask how has Hazelcast suddenly become that much faster than Redis? We believe it is down to some key design differences:
- Hazelcast IMDG uses highly optimized, multi-threaded clients and servers, and uses efficient asynchronous I/O. 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.
More than Speed
Hazelcast isn’t just about speed. We are a full In-Memory Data Grid (IMDG), with rich APIs for caching and in-memory computing, distributed concurrent data structures, distributed concurrency primitives and much more.
A major theme of the recent Hazelcast IMDG 3.8 release is a better operational experience for systems requiring maximum uptime. We added rolling member upgrades to complement our rolling client upgrades. We added user code deployment aka distributed classloader, so that you can add server side code to the running cluster without needing to restart nodes.
For details on the test environment, cluster topology, testing framework, configuration and in-depth benchmark results, download the benchmark here.
We are about a lot more than speed. But we are in the speed business, and speed matters. And as they say, quantity has a quality all of its own.