Re: 10X decrease in performance with Ignite 2.0.0

Hi Yakov, I was able to try these suggestions yesterday. 2.0.0 is now only a 19% decrease in performance -- versus the original 1000+% This is it in more detail: I do not truly understand the ramifications of using the

Re: 10X decrease in performance with Ignite 2.0.0

Chris, any news? --Yakov 2017-05-13 1:05 GMT+03:00 Denis Magda : > Chris, > > These are some links for reference: > > 1. BinaryObject and BinaryObjectBuilder interfaces usage: > https://apacheignite.readme.io/docs/binary-marshaller# > section-binaryobject-cache-api >

Re: 10X decrease in performance with Ignite 2.0.0

Chris, These are some links for reference: 1. BinaryObject and BinaryObjectBuilder interfaces usage: https://apacheignite.readme.io/docs/binary-marshaller#section-binaryobject-cache-api

Re: 10X decrease in performance with Ignite 2.0.0

Thank you. I will try on Monday (-ish) Yes, the objects are large. (average ~0.25MB) Could you please tell me the magic config I will need to try both these options? If not, I will do my homework. Thank you again, -- Chris -- View this message in context:

Re: 10X decrease in performance with Ignite 2.0.0

Chris, After looking at your code, the only slow down that may have occurred between 1.9 and 2.0 is the actual cache "get(...)" operation. As you may already know, Ignite 2.0 has moved data off-heap completely, so we do not cache data in the deserialized form any more, by default. However, you

Re: 10X decrease in performance with Ignite 2.0.0

Hi, I hope this helps. This is the flow. It is very simple. Although, the code in the ComputeJob (executor.compute(request, algType, correlationId);) is relatively application complex. I hope this code makes sense. I had to take the actual code and expunge all of the actual Domain bits from

Re: 10X decrease in performance with Ignite 2.0.0

Yakov, The entire reason we use the Compute Grid is because the data employed to do the compute is large (~0.25MB) and we compute 200 at once (spread across the grid -- so ~20 per Node w/ 10 Nodes). So I do not doubt that moving the data from off-heap-memory could be large. Is there a way to try

Re: 10X decrease in performance with Ignite 2.0.0

I think it will also be useful to switch to offheap tiered (cacheConfig.setMemoryMode()) in 1.9 and compare results again. --Yakov 2017-05-12 11:30 GMT+03:00 Alexey Goncharuk : > Hi Chris, > > One of the most significant changes made in 2.0 was moving to an off-heap

Re: 10X decrease in performance with Ignite 2.0.0

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

Re: 10X decrease in performance with Ignite 2.0.0

Absolutely agree here. I think if we can add getAll() benchmark and run it with batch sizes of 5 and 10. Thanks! -- Yakov Zhdanov, Director R *GridGain Systems* www.gridgain.com 2017-05-12 10:48 GMT+03:00 Sergi Vladykin : > According to our benchmarks Ignite 2.0 is not

Re: 10X decrease in performance with Ignite 2.0.0

According to our benchmarks Ignite 2.0 is not slower for get operation. I think we need some minimal reproducer that shows the performance degradation before making any conclusions. Sergi 2017-05-12 1:10 GMT+03:00 Yakov Zhdanov : > Cross-posting to devlist. > > --Yakov >

Re: 10X decrease in performance with Ignite 2.0.0

Cross-posting to devlist. --Yakov

Re: 10X decrease in performance with Ignite 2.0.0

Sergi Vladykin, do you think getAll() operation on B-Tree will help here? Now getAll() is a sequence of constant-time lookups. Situation is different for tree structures. So, we can traverse the tree only once given we have keys belonging to a single partition? --Yakov 2017-05-12 0:48 GMT+03:00

Re: 10X decrease in performance with Ignite 2.0.0

How many values are in your cache? SLB? What is it? >Will there be any difference between 1.9 and 2.0 if you send the same >number of empty jobs? >None. Exact same code . I want you to check if compute engine became slower in your deployment. If you comment out all lookups inside the job and run

Re: 10X decrease in performance with Ignite 2.0.0

Thank you so much for responding 1. You have 10 nodes with 4 partitioned caches each configured with 2 backups. There are no updates to the caches. Correct? Not really, no. 2. Are caches atomic or transactional? Atomic 3. 5 nodes send compute jobs to the topology of 10 nodes. Correct? No --

Re: 10X decrease in performance with Ignite 2.0.0

Chris, that's very surprising. Let's get to the bottom of it. 1. You have 10 nodes with 4 partitioned caches each configured with 2 backups. There are no updates to the caches. Correct? 2. Are caches atomic or transactional? 3. 5 nodes send compute jobs to the topology of 10 nodes. Correct? 4.