[jbosscache-dev] Optimize use of CacheLoader.exists() with passivation
Manik Surtani
manik at jboss.org
Tue Nov 25 08:45:17 EST 2008
On 24 Nov 2008, at 17:45, Brian Stansberry wrote:
> I've been profiling JBoss AS web session replication, and one of the
> significant hits I'm seeing is from calls to File.exists() from
> FileCacheLoader (see attached). In turn, those calls are due calls
> from LegacyActivationInterceptor, particularly the
> removeNodeFromCacheLoader() method, which is called with every
> invocation.[1] Many of these calls are on the most critical path[2]
> so speeding them can have large implications for overall cluster
> performance.
>
> I'm wondering if we can be smarter here and avoid most calls to
> removeNodeFromCacheLoader()?
>
> Is it a correct statement that, logically, with passivation the only
> time it would make sense to remove a node from the cache loader is
> if that invocation loaded data from the cache loader? The node
> remove is allowed because the in-memory data has become complete;
> the only way previously incomplete data can become complete is if a
> request has loaded data. So, if we can pass back to the activation
> interceptor info on whether a load has occurred (e.g. via a simple
> boolean flag in InvocationContext), we can avoid most calls to
> CacheLoader.exists().
>
> Thoughts?
Makes sense. See
https://jira.jboss.org/jira/browse/JBCACHE-1446
>
>
> [1] ActivationInterceptor would have the same problem if I were
> using MVCC.
> [2] Up calls from JGroups. NAKACK only allows one such call per peer
> at a time, and FC blocks web request threads based on the handling
> of these calls, so the speed of these calls is the most critical
> path in the whole system.
>
> --
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> brian.stansberry at redhat.com
> <
> websessreplhotspots
> .png>_______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
More information about the jbosscache-dev
mailing list