Hazelcast的执行速度较慢 [英] Hazelcast performing slower
问题描述
我们正在尝试将Hazelcast用作我们应用程序中的分布式缓存.这是我们的配置:
We are trying to use Hazelcast as distributed cache in our application. Here is our config:
<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作为默认的序列化程序并实现了近缓存.我们必须将每个大小为500KB的对象放入地图中，并且内存中可以包含大约400-500个这样的活动对象.我们在应用程序中经常使用缓存.
From the documentation, I can see that every time call is made to Hazelcast, de-serialization is involved. Hence to optmize the calls, we have used Kryo as default serializer and implemented near-cache. We have to put objects of size 500KB each into map and we can have around 400-500 such active objects in the memory. We use cache very often in the application.
之前，我们使用EhCache和为缓存实现配置的JGroups.操作相当快.但是，当我们尝试使用Hazelcast时，我发现运行时间存在一些可观的差异.我无法理解，Hazelcast不仅仅是缓存实现.但是，只是想知道为什么与EhCache(带有jgroups)相比，操作变得非常慢.我们所做的配置有什么问题吗?请提出建议！
Earlier we were using EhCache with JGroups configured for cache implementations. The operations were pretty faster. But when we tried to use Hazelcast, I see some considerable difference in operating time. I can unserstand that Hazelcast is more than a cache implementation. But just wondering why the operations became very slower when compared to EhCache(with jgroups). Is there some thing wrong with the configuration we have made? Please suggest!
还请注意，我正在单节点计算机上对此进行测试.
Also please note that I am testing this on a single node machine.
推荐答案
主要区别在于，EHcache最终是应用程序的本地缓存，而Hazelcast仍然是分布式缓存.但是，仅当-多次使用相同的对象时，Nearcache才能带来巨大的性能优势. Nearcache不是一种复制机制，而是一个简单的附加(本地)缓存层.
The main difference is, that EHcache ends up being a local cache to your application whereas Hazelcast is still a distributed cache. The Nearcache, however, should bring a big performance win if - and only if - you use the same objects multiple times. The Nearcache is not a replication mechanism but a simple additional (local) caching layer.
在3.8中，Continuous Query Caching是开源的，只要有更新，它就会自动更新本地缓存.另一个选择是查看ReplicatedMap，它将信息复制到集群中的每个单个节点(但仅集群成员，而CQC也会复制)对客户有效).
In 3.8 Continuous Query Caching is opensource and this will automatically update local caches whenever an update comes in. The other option is to look into ReplicatedMap which will replicate information to every single node in the cluster (but only cluster members whereas CQC also works on clients).
这篇关于Hazelcast的执行速度较慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
