[infinispan-dev] Consolidating temporary per-key data

[Radim Vansa]

On 12/01/2015 07:04 PM, Dan Berindei wrote:
> On Tue, Dec 1, 2015 at 5:13 PM, Radim Vansa <rvansa at redhat.com> wrote:
>> On 12/01/2015 03:26 PM, Dan Berindei wrote:
>>> On Tue, Dec 1, 2015 at 11:00 AM, Radim Vansa <rvansa at redhat.com> wrote:
>>>> 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.
>>> It makes sense if you consider tx caches, because the only way to
>>> cache these in the context for a transaction is to store them in
>>> another hashmap (a la `AbstractCacheTransaction.lookedUpEntries`).
>>>
>>> I know you're more interested in non-tx caches, but you have the same
>>> problem with the non-tx commands that use a NonTxInvocationContext
>>> (e.g. PutMapCommand).
>> lookedUpEntries is something completely different than I am talking
>> about, although it is also addressed by-key, but it's just *private to
>> the command invocation*.
>>
>> I was talking only about maps that are shared by *concurrent command
>> invocations* (as any map held in Interceptor).
> In your initial email, you said
>
>>>>>>> A reference to the
>>>>>>> entry could be stored in the context to save the lookups.
> How would you store those references in the context, if not in a map
> that's *private to the command invocation*?
>
> Remember, I'm talking about NonTxInvocationContext here, *not*
> SingleKeyNonTxInvocationContext.

This reference stored in a context is just an optimization that would 
help SingleKeyNonTxInvocationContext, it's not the focal point of the 
suggestion. Ok, for NonTxInvocationContext, you would either need

a) private map in the context - so you wouldn't have to lookup a big 
concurrent (=internally locking) map, but you would have to write to the 
map once
or
b) just lookup the big shared map

I really don't know which variant would prove more performant, and it's 
not *that* important. You're right, this *read optimization* is not 
possible for multi-key operations.

However the *write optimization* is there, you'd still write the shared 
map only once (ok, and then again for removal).

I should have structured the original mail in a better way, and state 
the (expected) major advantage, and further possible optimizations 
clearly separated.

Radim

>
> Cheers
> Dan
>
>> Radim
>>
>>>>> 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.
>>> I think you'd need something more like a refcount, and to atomically
>>> release the entry when the count reaches 0. (We used to have something
>>> similar for the locks map.) It's certainly doable, but the challenge
>>> is to make it cheaper to maintain than the separate maps we have now.
>>>
>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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