[infinispan-dev] Time measurement and expiry

[Manik Surtani]

On 30 Oct 2011, at 23:58, Dan Berindei wrote:

> Cool link Elias, I read the paper linked in the javadoc and it's very
> interesting.
> 
> Netty seems to use scheme 6 (a single array of lists with hashing and
> without any overflow). I believe in general our timeouts will be much
> longer so I suspect scheme 5 or scheme 7 should perform better for us.
> 
> Scheme 5 should be much better than 6 if most of the timeouts use the
> same value, and I believe we fit right in that use case.
> On the other hand I think we could save some memory if we implement
> scheme 7 by not actually storing the higher level wheels and building
> them on the fly by iterating the data container. The downside is that
> we'll need periodic sweeps of the data container, but those can be on
> a separate thread.

-1.  I'd prefer an approach that does not involve any additional management threads.

> One scenario that we should keep in mind is the L1 cache, whose
> entries I would guess are invalidated much more often than they expire
> after their 1 hour lifetime. If the user stores only immortal entries
> + L1 entries in the cache we might end up with a ticker task that
> never rarely does anything useful so we should minimize its impact.
> 
> It might also be worth it to implement our own list type to make
> adding and removing timeouts faster. I see Netty uses
> IdentityHashMap-backed sets for the bucket lists, but as Sanne found
> out they aren't the fastest thing around. Using a doubly-linked list
> and keeping a reference to the Node in the cache entry should make it
> much faster.

Yes, I think implementing our own is the way forward as well.  No sense in adding dependencies for just a single class, etc.

Cheers
Manik
--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org