[infinispan-dev] Time measurement and expiry

[Sanne Grinovero]

On 27 October 2011 16:58, Manik Surtani <manik at jboss.org> wrote:
>
> On 20 Oct 2011, at 08:47, Galder Zamarreño wrote:
>
> Why are we preferring to provide more cache misses && slower
>
> performance, to fake a slightly better precision in eviction?
>
>
> I guess this is the main question, how much worse would the eviction
>
> precision be if we only relied on the periodic eviction thread?
>
> We did use to have a periodic eviction thread in the JBoss Cache days, but
> that used to cause us problems since we queued events to the cache in order
> to apply eviction algorithms.
>
> That was a different case.  In JBC we picked nodes for eviction and put them
> on an eviction queue and they were analysed periodically.  That queue became
> a bottleneck.
> The suggestion here is to essentially cache time lookups so that you don't
> call System.cTM() all the time.  See Elias Ross' parallel post to this list
> about Netty's HashedWheelTimer.
> Sanne, I recall your creating a JIRA for this?

Yes I created ISPN-1459 as a starting point, only to not look at the
clock for each entry during an eviction iteration.
I have an experimental branch implementing a POC and a test with fills
the cache with 10.000.000 small entries, the eviction thread is twice
as fast than before, and using less CPU too. I hoped better, but still
worth to polish it.
So that makes me think that it would benefit all non-immortal entries
also during read operations to remove this same check, but I can't
move the time read out of the entry code without introducing a new
overhead to the read of immortal entries - which are dearer to me :)
So to get the best benefit for both cases I'll have to do some more
experiments, after JUDcon and current OGM priorities.

Sanne