CLUSTERING YOUR APPLICATION WITH HAZELCAST

As you may know we have issues with our cached Lucene indexes in WatchPro and I already had a look at Hazelcast a few weeks ago but Christoph told me there are some performance issues (sometimes 100% CPU) with it. Anyway I thought this session could throw some light on it. Hazelcast is not only a partitioned cache across a cluster of nodes, it also has a mechanism to execute code on the node that is containing the data. This would be a perfect match to cache our Lucene indexes.  Now each server has its own cache which is way too small to cache all of the Lucene indexes of our biggest customers. As a result the Lucene indexes are retrieved from the database over and over again which leads to poor performance especially if we need to fetch a large amount of Lucene indexes. But if we could use all the memory and disk storage of our 8 watch servers to make one big Lucene Index cache, this might actually work. I think the performance issues with Hazelcast are related to the backup mechanism. By default every cache entry has a backup entry in one of the other nodes. This is a feature we can do without and apparently you can set the backup count to zero.  We should give it a try.