On 19 Jun 2013, at 16:43, Sanne Grinovero <sa...@infinispan.org> wrote:
> On 19 June 2013 15:35, cotton-ben <ben.cot...@alumni.rutgers.edu> wrote: >> / >>>> 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: >>> [...] >>> At the opposite site, I don't see how - as a user - I could optimally >> tune a separate container. / >> >> There is 1 place where this is important from the User's view. Users want >> (and actually need) to be able to tune their expectations for their >> Cache/Grid provider's L1 capability join-point. Specifically, a user can be >> greatly empowered if their provider provides an API that assist the user's >> preference for "where he wants to be" on the get(K) probability of "hit@L1" >> vs. get(K) probability of "readThrough@remoteContainer" distribution curve. > > Indeed, IFF you separate the two storage areas you get in that kind of > need, but I think it's an unnecessary complexity. The world is > actually quite simple: you have N gigs of heap available, you can > estimate you want your LIRS strategy to target some M number of > entries. > Which entries exactly, you will never be able to make a good choice, > but LIRS (or other eviction strategies) are able to make a decision > which is easy to model. > > This whole discussion is starting from the assumption that it is > important to keep the owned entries in memory; I don't think we should > blindly assume that. > If someone could explain an important reason to always favour owned > entries over *hotter* entries I'd be less skeptical, but even so that > would be a step backwards in ease of configuration as today the grid > basically self-tunes ergonomically. +1 Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
