Hazelcast is slow when put data to distributedmap

user_10544956 0
Viewed 2399

I have two hazelcast nodes (16GB RAM, 4 core per node).when i tried put to distributed map,hazelcast was very slow (1904 puts/s) but if i shutdown one node, performance is increase (30000 puts/s). Anyone can help me turning performance in multi nodes ?. Thank you

hazelcast java
2 Answers

Please check the configurations you are having. You must be having synchronous backup as a result your put query is completed when the data is replicated to another node. This is the default configuration.

You can use asynchronous backup to improve performance. But this will hamper the consistency of the system.

More info on Consistency:

In the context of CAP theorem, Hazelcast is an AP product. Thus, Best-Effort Consistency is aimed on replication and both sync and async backups are implementations of the lazy replication model. As it is explained in the page; the difference between two options is;

  • Sync backups, the caller block until backup updates are applied by backup replicas and acknowledgments are sent back to the caller
  • Async backups works as fire & forget. Below, please see the part from Hazelcast Reference Manual:

Hazelcast's replication technique enables Hazelcast clusters to offer high throughput. However, due to temporary situations in the system, such as network interruption, backup replicas can miss some updates and diverge from the primary. Backup replicas can also hit long GC pauses or VM pauses, and fall behind the primary, which is a situation called as replication lag. If a Hazelcast partition primary replica member crashes while there is a replication lag between itself and the backups, strong consistency of the data can be lost.

user_64486560

I run embed instance ,using data-serializable, key is String[25chars], value is Object {String[25chars], String[25 chars] }

    <in-memory-format>OBJECT</in-memory-format>


    <backup-count>0</backup-count>

    <async-backup-count>1</async-backup-count>
    <!--
        Maximum number of seconds for each entry to stay in the map. Entries that are
        older than <time-to-live-seconds> and not updated for <time-to-live-seconds>
        will getMSISDN automatically evicted from the map.
        Any integer between 0 and Integer.MAX_VALUE. 0 means infinite. Default is 0
    -->
    <time-to-live-seconds>864000</time-to-live-seconds>
    <!--
        Maximum number of seconds for each entry to stay idle in the map. Entries that are
        idle(not touched) for more than <max-idle-seconds> will getMSISDN
        automatically evicted from the map. Entry is touched if getMSISDN, putMSISDN or containsKey is called.
        Any integer between 0 and Integer.MAX_VALUE. 0 means infinite. Default is 0.
    -->
    <max-idle-seconds>864000</max-idle-seconds>
    <!--
        Valid values are:
        NONE (no eviction),
        LRU (Least Recently Used),
        LFU (Least Frequently Used).
        NONE is the default.
    -->
    <eviction-policy>LRU</eviction-policy>

    <near-cache>
        <max-size>0</max-size>
        <time-to-live-seconds>864000</time-to-live-seconds>
        <max-idle-seconds>864000</max-idle-seconds>
        <eviction-policy>LRU</eviction-policy>
        <invalidate-on-change>true</invalidate-on-change>
        <in-memory-format>BINARY</in-memory-format>
        <cache-local-entries>false</cache-local-entries>
        <eviction size="1000" max-size-policy="ENTRY_COUNT" eviction-policy="LFU"/>
    </near-cache>
</map>
user_105449560
Related