[infinispan-dev] Consolidating temporary per-key data

[Radim Vansa]

On 11/30/2015 08:17 PM, Dan Berindei wrote:
> The first problem that comes to mind is that context entries are also
> stored in a map, at least in transactional mode. So access through the
> context would only be faster in non-tx caches, in tx caches it would
> not add any benefits.

I admit that I was thinking more about non-tx caches, I would have to 
re-check what maps are written tx mode. Please, let's focus on non-tx.

However I probably don't comprehend your answer completely. I am not 
talking that much about reading something from the context, but reads 
from these concurrent maps (these can be always somehow cached in the 
context), but about writes.

>
> I also have some trouble imagining how these temporary entries would
> be released, since locks, L1 requestors, L1 synchronizers, and write
> registrations all have their own rules for cleaning up.

Maybe I am oversimplifying that - all the components would modify the 
shared record, and once the record becomes empty, it's removed. It's 
just a logical OR on these collections.

>
> Finally, I'm not sure how much this would help. I actually removed the
> write registration for everything except RemoveExpiredCommand when
> testing the HotRod server performance, but I didn't get any
> significant improvement on my machine. Which was kind of expected,
> since the benchmark doesn't seem to be CPU-bound, and JFR was showing
> it with < 1.5% of CPU.

Datapoint noted. But if there's application using embedded Infinispan, 
it's quite likely that the app is CPU-bound, and Infinispan becomes, 
too. We're not optimizing for benchmarks but apps. Though, I can see 
that if server is not CPU bound, it won't make much difference.

Thanks for your opinions, guys - if Will will remove the expiration 
registration, this idea is void (is anyone really using L1?). We'll see 
how this will end up.

Radim

>
> Cheers
> Dan
>
>
> On Fri, Nov 27, 2015 at 11:28 AM, Radim Vansa <rvansa at redhat.com> wrote:
>> No thoughts at all? @wburns, could I have your view on this?
>>
>> Thanks
>>
>> Radim
>>
>> On 11/23/2015 04:26 PM, Radim Vansa wrote:
>>> Hi again,
>>>
>>> examining some flamegraphs I've found out that recently the
>>> ExpirationInterceptor has been added, which registers ongoing write in a
>>> hashmap. So at this point we have a map for locks, map for writes used
>>> for expiration, another two key-addressed maps in L1ManagerImpl and one
>>> in L1NonTxInterceptor and maybe another maps elsewhere.
>>>
>>> This makes me think that we could spare map lookups and expensive writes
>>> by providing *single map for temporary per-key data*. A reference to the
>>> entry could be stored in the context to save the lookups. An extreme
>>> case would be to put this into DataContainer, but I think that this
>>> would prove too tricky in practice.
>>>
>>> A downside would be the loss of encapsulation (any component could
>>> theoretically access e.g. locks), but I don't find that too dramatic.
>>>
>>> WDYT?
>>>
>>> Radim
>>>
>>
>> --
>> Radim Vansa <rvansa at redhat.com>
>> JBoss Performance Team
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team