Hot Restart Store Performance Benchmark

This benchmark tests the write and read performance of the Hot Restart Store, introduced in Hazelcast® Enterprise HD 3.6. All benchmarks test the performance of one Hazelcast member running on a physical server. As the Hot Restart Store is local to each member, performance is linearly scalable.

The Hazelcast Hot Restart Store is novel in that it is only ever written to when the cluster is operational. It is never read from. It is only read during start up where we read the entire store into memory before enabling operations. All operational reads are therefore always to RAM.

Results Summary

There are two questions on performance that are important: write performance and read performance.

• Can the Hot Restart Store keep up with writes in the cluster?
  • With SSD each member can write 220,000 to 310,000 writes per second. This is well above the typical workload for a single member.
  • With HDD each member write 35,000 to 45,000 writes per second. This may impact write performance of a typical cluster. HDD is recommended only for clusters with small amounts of data or slowly changing data such as reference data.
• How long does it take to restart the cluster?
  • With SSD each member can load data at 1.22GB/s to 1.28GB/s giving a startup time for a 100GB per member of 78 seconds. So a 1TB cluster of 10 members would start up in 78 seconds.
  • With HDD each member can load data at .05GB/s to .08GB/s giving a startup time for 10GB per member of 3.5 minutes. HDD is recommended only for clusters with small amounts of persistent data.

Server Hardware

All tests were performed on HP ProLiant servers running RHEL 7

Storage Media

Two common types of media were tested: 10k HDD and Solid State Drives.

Test Configuration

Tests were performed using Hazelcast Simulator:

• custom test class (CycleRunAndRestart)
• single-member cluster
• IMap with varying HD Memory sizes; 1KB values
• For write testing, user threads call IMap methods concurrently
• various numbers of operation threads. By default Hazelcast will use the number of CPU cores. Testing was done at various numbers to show the effect of more cores and hence operations threads. More threads allows more work to be done in parallel.