Sorry, I do not have trace for scan query.
We moved away from the earlier implementation, as of now it is not showing
big latencies like earlier.
Thank you for help.
Thanks,
-Sam
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Sam,
Entry processor is indeed executed within a lock, this is required to
achieve atomicity. So if there is high contention on a single key, requests
will wait for each other. And this is yet another reason to make entry
processor implementation as lightweight as possible so that it does not
acqu
Thanks Val.
I understand Array copy is heavy operation and probably lots of memory
allocations too, however, my profiler showing complete logic of copy and
append taking 50% of the total time taken by Invoke call. that's why the
question, does invoke should take this much time or its the concurren
Hi Sam,
What does this byte array represent? You have to array copies in the entry
processor, so I'm not surprised it doesn't perform very well. That's also
the reason why it gets worse when size of the array is increased. The fact
that you're using off-heap also make it worse in this case as it b
Sam,
>>
Why does invoking remote method is taking 50% of time? Is it because of
concurrency and entry processor will execute under a lock internally?
>>
Could you please share a small reproducer project.
>> Is there any better way to deal with this usecase?
Have you tested with only heap memory?
Thanks Pavel for reply.
/"When you store entries into the off-heap, any update operation requires
copying value from the off-heap to the heap." /
I am updating using remote entry processor, does that also need to copy
value to calling heap? If yes then no benefit using entry processor here, I
can
Hi Sam,
When you store entries into the off-heap, any update operation requires
copying value from the off-heap to the heap.
Thus frequent updates of the "heavy" entry lead to significant overheads
for copying data.
Have you tested only with the heap memory?
Thanks,
Pavel
2018-04-05 4:44 GMT+0
