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 <
[hidden email]> 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.
>
Locked
