[infinispan-dev] L1 Data Container
Mircea Markus
mmarkus at redhat.com
Mon Jul 8 08:50:56 EDT 2013
On 19 Jun 2013, at 16:19, Sanne Grinovero <sanne at infinispan.org> wrote:
> On 19 June 2013 13:44, William Burns <mudokonman at gmail.com> wrote:
>> All the L1 data for a DIST cache is stored in the same data container as the
>> actual distributed data itself. I wanted to propose breaking this out so
>> there is a separate data container for the L1 cache as compared to the
>> distributed data.
>>
>> I thought of a few quick benefits/drawbacks:
>>
>> Benefits:
>> 1. L1 cache can be separately tuned - L1 maxEntries for example
>
> -1!
> I don't think thats a benefit actually, from the point of view of a user:
> as a user I only know I have a certain amount of memory available on
> each node, and the application is going to use certain data way more
> often than others.
> The eviction strategy should be put in condition to be able to make an
> optimal choice about which entries - among all - are better kept in
> memory vs. passivated.
> I don't see a specific reason to "favour" keeping in memory owned
> entries over an L1 entry: the L1 entry might be very hot, and the
> owned entry might be almost-never read.
> Considering that even serving a Get operation to another node (as
> owners of the entry) makes the entry less likely to be passivated (it
> counts as a "hit"), the current design naturally provides an optimal
> balance for memory usage.
>
> At the opposite site, I don't see how - as a user - I could optimally
> tune a separate container.
Very good points Sanne.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
More information about the infinispan-dev
mailing list