ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scottmf <scott...@gmail.com>
Subject tuning near cache performance
Date Tue, 20 Feb 2018 22:58:16 GMT
Hi, 
In one of our services we have need for a shared cache across multiple jvms. 
Currently these objects are being exposed to the application logic via a
local hashmap and synchronized via a custom mechanism.  We'd like to replace
this mechanism with ignite where the service cluster nodes would become
ignite clients.  Currently the idea is to use an Ignite cluster cache / near
cache then we'd throw away the custom cross node synchronization logic.  The
Cache is very read heavy with a small volume of writes over time. 

When I switched over the mechanism to Ignite I found that the near cache
needs some tuning.  The first thing I noticed was the serialization /
deserialization bottleneck.  I found a post from Val that said to turn off
copyOnWrite.  This alleviated the major bottleneck that I saw but the
performance is still slower than using a local HashMap.  Although I
understand that it may never get to the performance of a local HashMap I was
wondering what other tuning tips I need to know about in order to speed up
our reads from the near cache. 

Currently I see this (more or less) as the bottleneck: 

org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.init 
  -->
org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.map 
    --> GridIteratorAdapater.next 
    -->
org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.map 
      --> GridCacheAdapter.peekEx 
      --> GridCacheEvictionManager.touch 
      --> GridNearGetFuture.addResult 

Are there other knobs that I can turn in order to tune this to better serve
my workload? 

thanks, 
Scott



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Mime
View raw message