Re: [infinispan-dev] Time measurement and expiry
On 27 October 2011 16:58, Manik Surtani <manik(a)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