Hi Amit. 1) Performance degradation may be caused by long GC pauses. Please check [1] for hints on how to set up GC settings properly. If you plan to have very large caches, I recommend using OFFHEAP_TIERED mode [2]
I assume you take the aproach like IgniteCache<Integer, List<Cell>> How many cells do you have in single row ? 2) Try to use cache.invokeAll on all keys at once. [1] https://apacheignite.readme.io/docs/jvm-and-system-tuning [2] https://apacheignite.readme.io/docs/off-heap-memory 2016-06-02 9:26 GMT+03:00 pragmaticbigdata <[email protected]>: > Hi Alexei, I was able to implement this custom logic based on your guidance > below. Thanks for that. I do experience a couple of performance issues. > > 1. With a caching having 1 million entries, updating 11k entities 5 times > (cached entities are updated multiple times in the application) took 1 min. > The cluster configuration includes 5 server nodes with 16 cpu cores and 15 > GB RAM. The cache is a partitioned cache with 0 backups. Can these timings > be improved? > > 2. I tried using the compute colocation feature by having a affinityRun() > but that seems to be degrading the performance otherwise. Making an > affinity > call through affinityRun() method by passing a Callable resulted into a > poor > performance compared to the default execution. The code does a localPeek > and > updates that cache entry along with returning one of the properties from > the > cached object. Would you have inputs on what could be the problem? The code > looks like below > > for(String key : keyValues) { > > outputValues.add(ignite.compute().affinityCall(productCache.getName(), key, > () -> updateCacheEntry(key, productCache.localPeek(key)))); > } > > Kindly let me know your suggestions. > > > > -- > View this message in context: > http://apache-ignite-users.70518.x6.nabble.com/Simulating-Graph-Dependencies-With-Ignite-tp5282p5369.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. > -- Best regards, Alexei Scherbakov
