Hi Chris, One of the most significant changes made in 2.0 was moving to an off-heap storage by default. This means that each time you do a get(), your value gets deserialized, which might be an overhead (though, I would be a bit surprised if this causes the 10x drop).
Can you try setting CacheConfiguration#setOnheapCacheEnabled(true) and check if performance gets back? 2017-05-11 17:45 GMT+03:00 Chris Berry <chriswbe...@gmail.com>: > Hello, > > We are currently migrating a high volume/low latency system to use Ignite. > And we were excited by the claims of Ignite 2.0 to have great performance > improvements. > So we did a performance test of it last night. > > Unfortunately, we saw a 10X DECREASE in performance over 1.9. > This is using the exact same code. And running the 2 tests (1.9 vs 2.0) > back to back (in AWS). > > Our test system is relatively simple. It is a 10 Node Compute Grid. Hit > from 5 load generators running in the same AWS Region. > We rely heavily on cache affinity -- wherein we use 4 Partitioned caches > (each w/ 2 backups) – all using the same cache Key (a UUID). > > We use a simple ComputeTask – mapping jobs (UUIDs) out to the grid – and > then collecting them after. > > The ComputeJob then does all of it’s lookups using localPeek (to ensure we > stay on-box) > The system is almost all Reads. > > This system – under high load – computing in batches of 200 UUIDs – was > responding to our tests (in 1.9.0) at 53ms Mean with 1370 batches/sec > In 2.0.0 – we are getting a 574ms Mean with 134 batches/sec > > Clearly we are missing a tuning parameter w/ 2.0.0?? > > BTW: On the positive side, I do see significantly less Heap usage with > 2.0.0. > > I realize that I am being a bit vague on code specifics. > > But a lot of that needs to be “expunged” before I can post it to the > public internet. > > Although, I can provide whatever necessary, I hope…. > Thanks, > -- Chris > > >
