Blog ›Hazelcast IMDG Faster than Redis and Extending its Lead

By Greg Luck

Chief Technical Officer

Greg Luck is a leading technology entrepreneur with more than 15 years of experience in high-performance in-memory computing. He is the founder and inventor of Ehcache, a widely used open source Java distributed cache that was acquired by Software AG (Terracotta) in 2009, where he served as CTO. Prior to that, Greg was the Chief Architect at Australian start-up Wotif.com that went public on the Australian Stock Exchange (ASX:WTF) in 2006. Greg is a current member of the Java Community Process (JCP) Executive Committee, and since 2007 has been the Specification Lead for JSR 107 (Java Specification Requests) JCACHE. Greg has a master's degree in Information Technology from Queensland University of Technology and a Bachelor of Commerce from the University of Queensland.

View all blogs by the author

Apr 25, 2017

Back to Blog

Hazelcast IMDG Faster than Redis and Extending its Lead

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.

Hazelcast Faster

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.

Why?

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.