[jbosscache-dev] Optimize use of CacheLoader.exists() with passivation

[Brian Stansberry]

Manik Surtani wrote:
> 
> 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
> 

That helps. I see now though that there are also calls via the tx 
prepare processing -- 
LegacyActivationInterceptor$ActivationModificationsBuilder.handlePutCommand() 
(see attached).

I'm not sure exactly what that logic is doing, so I won't try to comment 
on whether tracking whether nodes were loaded in the TransactionContext 
makes sense. :)

I'm working to eliminate the biggest hotspot in the attached graphic; 
once I do I'll test w/ CR1 vs CR2 to get a feel for how much 
JBCACHE-1446 improved things.

...done...

w/ 3.0.1.CR1: 3677 req/sec
w/ 3.0.1.CR2: 3955 req/sec
no CL at all: 4930 req/sec (w/ CR2; CL config is commented out)


>>
>>
>> [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
> 


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: File.exists.png
Type: image/png
Size: 146199 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbosscache-dev/attachments/20081125/56ab62a3/attachment.png