Pra*_*nth 2 java performance ehcache hazelcast hazelcast-imap
我们正在尝试在我们的应用程序中使用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>
Run Code Online (Sandbox Code Playgroud)
从文档中,我可以看到,每次调用Hazelcast时,都会涉及反序列化.因此,为了优化调用,我们使用Kryo作为默认序列化器并实现了近缓存.我们必须将每个大小为500KB的对象放入地图中,并且我们可以在内存中有大约400-500个这样的活动对象.我们经常在应用程序中使用缓存.
之前我们使用EhCache和JGroups配置缓存实现.操作速度非常快.但是当我们尝试使用Hazelcast时,我发现操作时间有很大差异.我可以说,Hazelcast不仅仅是一个缓存实现.但只是想知道为什么与EhCache(使用jgroups)相比,操作变得非常慢.我们的配置是否有问题?请指教!
另请注意,我正在单节点机器上测试它.
所有分布式缓存解决方案都会产生序列化成本.由于您希望数据存在于JVM之外,因此无法绕过它.
使用JGroups进行复制的Ehcache可能通过异步执行复制来隐藏此成本,但您在此设置中实际上保持了零一致性保证.
无论是使用Ehcache还是Hazelcast,分布式解决方案都能提供一致性保证.但由于一致性执行,这增加了成本.