I hardly can imagine use case hundreds of caches with expiry policies. Even if someone really need it, what is the real performance impact? Considering some mid-level server with 64 cores we already have ~4 nio threads and ~64 system pool threads processing cache operations. All these threads constantly switch back and forth. This is how Ignite works for years and I doubt we currently consider this as a performance issue. So I doubt we have any problem with TTL context switches for now.
As per entering critical section inside TTL manager, again - it should be benchmarked first. E.g. cache with expiry policy vs cache w/o expiry policy. Even in contented case JVM allows for millions enter-leave cycles per second for "synchronized" block. So I doubt it is a problem either. On Wed, Aug 3, 2016 at 1:46 PM, Eduard Shangareev < [email protected]> wrote: > Now every cache has own TTL manager, which creates CleanupWorker = new > extra thread. This can cause to extra hundreds of threads (redundant > context switches = performance penalty). > > Also, under IGNITE-3513 > <https://issues.apache.org/jira/browse/IGNITE-3513> every > put can enter critical section to notify worker. Obviously, it is not good > from performance point of view. > > So, my proposal is next: > 1. Expiration should be done on every cache action (on exit thread which > updates cache should invoke expire). > 2. TtlManager will exist only in one instance. > 3. CleanupWorker will be the only backup if there is no cache activity. It > will wake up with some period to check for work (500 ms, for example). > > Moreover, now we keep on-heap pending entries even if a cache is kept > off-head. At least, this issue needs discussion. >
