On 12/01/2015 07:04 PM, Dan Berindei wrote: > On Tue, Dec 1, 2015 at 5:13 PM, Radim Vansa <[email protected]> wrote: >> On 12/01/2015 03:26 PM, Dan Berindei wrote: >>> On Tue, Dec 1, 2015 at 11:00 AM, Radim Vansa <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>>> JBoss Performance Team >>>>>> >>>>>> _______________________________________________ >>>>>> infinispan-dev mailing list >>>>>> [email protected] >>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>> _______________________________________________ >>>>> infinispan-dev mailing list >>>>> [email protected] >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> -- >>>> Radim Vansa <[email protected]> >>>> JBoss Performance Team >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> [email protected] >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> _______________________________________________ >>> infinispan-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Radim Vansa <[email protected]> >> JBoss Performance Team >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <[email protected]> JBoss Performance Team _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
