Hazelcast работает медленнее

Мы пытаемся использовать Hazelcast в качестве распределенного кеша в нашем приложении. Вот наш конфиг:

<hazelcast xsi:schemaLocation="http://www.hazelcast.com/schema/config hazelcast-config-3.7.xsd" xmlns="http://www.hazelcast.com/schema/config"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <group>
      <name>sample_dev</name>
      <password>dev@123</password>
   </group>
   <management-center enabled="false">http://localhost:8080/mancenter</management-center>
   <properties>
      <property name="hazelcast.logging.type">slf4j</property>
      <property name="hazelcast.socket.bind.any">false</property>
   </properties>
   <serialization>
      <serializers>
         <global-serializer override-java-serialization="true">com.prasanth.common.KryoSerializer</global-serializer>
      </serializers>
   </serialization>
   <network>
      <join>
         <multicast enabled="false"/>
         <tcp-ip enabled="true">
            <member-list>
               <member>127.0.0.1:5701</member>
            </member-list>
         </tcp-ip>
      </join>
      <interfaces enabled="false">
         <interface>192.168.3.*</interface>
      </interfaces>
   </network>
   <map name="com.prasanth.cache.CachedAsset">
      <in-memory-format>BINARY</in-memory-format>
      <backup-count>1</backup-count>
      <async-backup-count>1</async-backup-count>
      <time-to-live-seconds>86400</time-to-live-seconds>
      <max-idle-seconds>1200</max-idle-seconds>
      <eviction-policy>LRU</eviction-policy>
      <max-size policy="PER_NODE">4500</max-size>
      <merge-policy>com.hazelcast.map.merge.LatestUpdateMapMergePolicy</merge-policy>
      <!--<read-backup-data>true</read-backup-data>-->
      <near-cache>
         <in-memory-format>OBJECT</in-memory-format>
         <cache-local-entries>true</cache-local-entries>
         <time-to-live-seconds>86400</time-to-live-seconds>
         <max-idle-seconds>1200</max-idle-seconds>
         <invalidate-on-change>true</invalidate-on-change>
      </near-cache>
   </map>
</hazelcast>

Из документации я вижу, что каждый раз, когда делается вызов Hazelcast, происходит десериализация. Следовательно, чтобы оптимизировать вызовы, мы использовали Kryo в качестве сериализатора по умолчанию и внедрили почти кэш. Мы должны поместить объекты размером 500 КБ каждый в карту, и у нас может быть около 400-500 таких активных объектов в памяти. Мы очень часто используем кеш в приложении.

Раньше мы использовали EhCache с JGroups, сконфигурированными для реализации кэша. Операции прошли намного быстрее. Но когда мы попробовали использовать Hazelcast, я увидел существенную разницу во времени работы. Я могу понять, что Hazelcast — это больше, чем реализация кеша. Но просто интересно, почему операции стали очень медленными по сравнению с EhCache (с jgroups). Что-то не так с нашей конфигурацией? Пожалуйста, предложите!

Также обратите внимание, что я тестирую это на машине с одним узлом.


person Prasanth    schedule 13.03.2017    source источник


Ответы (2)


Основное отличие состоит в том, что EHcache становится локальным кешем для вашего приложения, тогда как Hazelcast по-прежнему остается распределенным кешем. Однако Nearcache должен принести большой выигрыш в производительности, если — и только если — вы используете одни и те же объекты несколько раз. Nearcache — это не механизм репликации, а простой дополнительный (локальный) уровень кэширования.

В 3.8 Continuous Query Caching является открытым исходным кодом, и это будет автоматически обновлять локальные кеши всякий раз, когда поступает обновление. Другой вариант — просмотреть ReplicatedMap, который будет реплицировать информацию на каждый отдельный узел в кластере (но только на члены кластера, тогда как CQC также работает на клиентах). ).

person noctarius    schedule 13.03.2017
comment
Один быстрый вопрос. Я определил максимальный размер на узел как 4500. Это нормально? У нас есть кластер из 3 узлов, и по умолчанию имеется 271 раздел, и я включу как синхронное, так и асинхронное резервное копирование. Таким образом, у меня будет 270/3=90 разделов, несущих первичные данные, а остальные 180 будут иметь резервные данные других узлов. И я предположил, что мы можем сохранить до 50 элементов на раздел и, следовательно, 90 * 50 = 4500. Эта конфигурация правильная? Откуда мне знать, сколько элементов может храниться в одном разделе? - person Prasanth; 15.03.2017
comment
Нет, у вас 271 раздел данных, копии этих разделов попадают на другие узлы кластера. Тем не менее: 1 резервная копия = 271 раздел данных + 271 резервный раздел. - person noctarius; 15.03.2017
comment
docs.hazelcast.org/docs/3.7/ manual/html-single/ Из этой ссылки я подумал, что по умолчанию узел будет иметь 271 раздел, в котором будут как основные, так и резервные данные. В моем случае, поскольку у меня есть 2 резервных копии данных для каждого узла, я предположил, что у нас останется только ~ 90 основных разделов на узел. Разве это не так? - person Prasanth; 16.03.2017
comment
Нет, в кластере 271 раздел плюс резервные разделы. 1 резервная копия = 1x271 резервная копия, 2 резервные копии = 2x271 резервная копия. Очевидно, что с одним узлом будет ТОЛЬКО 271, так как нет смысла иметь резервные копии на одном узле. - person noctarius; 17.03.2017
comment
так где же находятся эти резервные копии 2*271? - person Prasanth; 17.03.2017
comment
на всех узлах... распределены поровну... смотрите картинки в документации. - person noctarius; 18.03.2017

Все решения для распределенного кэширования будут нести расходы, связанные с сериализацией. Поскольку вы хотите, чтобы данные находились за пределами JVM, это невозможно.

Ehcache с репликацией с использованием JGroups, вероятно, скрывал эту стоимость, выполняя репликацию асинхронно, но в этой настройке у вас были фактически нулевые гарантии согласованности.

Распределенные решения, независимо от того, используют ли они Ehcache или Hazelcast, гарантируют согласованность. Но это увеличивает стоимость из-за обеспечения согласованности.

person Louis Jacomet    schedule 14.03.2017