1

In IMap configuration there is an attribute read-backup-data that can be set as true which enables a member to read the value from the backup copy, if available, in case the owner of the key is some other member.

http://docs.hazelcast.org/docs/latest-development/manual/html/Distributed_Data_Structures/Map/Backing_Up_Maps.html#page_Enabling+Backup+Reads

Then there is nearcache which will start caching results for a few datastructures locally.

http://docs.hazelcast.org/docs/latest-development/manual/html/Performance/Near_Cache/Hazelcast_Data_Structures_with_Near_Cache_Support.html

If we have 2 kinds of cluster setup:

  1. 2 members, and async-backup-count for a map is 1, and read-backup-data is true
  2. 2 members, nearcache enabled for this map

Would there be differences in these 2 approaches?

1st setup will probably use less memory, and will not be configurable. But in terms of read performance?

neeraj
  • 1,191
  • 4
  • 19
  • 47

1 Answers1

2

For two member cluster setup; enabling backup reads will provide you to access all the data locally, since both members hold all the entries as either primary or backup. This setup is not much different than using a Replicated Map (see here for details: http://docs.hazelcast.org/docs/latest-development/manual/html/Distributed_Data_Structures/Replicated_Map.html). So; when your cluster have only two members (also no clients), enabling backup reads can be more advantageous in terms of performance.

However; near cache has a bunch of configuration options, and you can decide how much data you need to access locally at any type of setup (including client-server topology). You can also decide the in-memory data format in near cache. These options can provide you more performance than enabling backup reads.

Both options are not so much different in single entry read performance (I assume near cache contains valid entry), since both don't perform a remote operation.

Alparslan Avci
  • 931
  • 4
  • 6
  • I am running such a cluster with `read-backup-data ` as true. Can I confirm using management center (or something else) that backups are actually being read? Avg PUT latencies in management center show around 5 ms, while the average GET latency is much higher, of the order of 50 ms. I just want to be sure that Gets could be slower because of thread contention in my application and data is actually being read from the backup. – neeraj Jan 31 '18 at 10:49
  • actually the get and put throughput is almost similar. Could there be a reason why puts are so much faster than gets? – neeraj Jan 31 '18 at 11:08
  • For some strange reason puts/s and gets/s are EXACTLY the same for all maps in management center. In all monitoring tools we have, we can see that we have a lot of cache hits that has brought our overall latencies down. – neeraj Jan 31 '18 at 11:28
  • It is difficult to comment without investigating all your use-case and cluster configuration since get latency can be affected from many other cases (such as `MapLoader`). But I don't think it is related to thread contention. If it was so, you also see higher latencies in puts because put and get ops are run in the same threads. – Alparslan Avci Jan 31 '18 at 11:58
  • Ok. If it helps, I am using spring boot hazelcast, where I don't manage maps explicitly. Something similar to this: https://github.com/hazelcast/hazelcast-code-samples/blob/master/hazelcast-integration/springboot-caching/src/main/java/com/hazelcast/springboot/caching/IDummyBean.java And I am not doing any writes, my reads are just going to another service, getting some data, and caching it in the map. Does the length of key name matter here to explain difference between put and get latencies? And in general according to you, put and get latencies should give almost similar performance? – neeraj Jan 31 '18 at 14:14
  • Hey checking again for a small query: Is there a way to confirm whether backup data is actually being read or not? – neeraj Feb 04 '18 at 10:51