ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: IGNITE-3621 Implementation details
Date Wed, 03 Aug 2016 11:28:06 GMT
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 <
eduard.shangareev@gmail.com> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message