.....following on from my email titled "Profiling shows Session management to be a hotspot - session pooling etc"
After further analysis a lot the CPU time was spent in PropertyId.toString(). This was called by various blocks surronded by "if (log.isDebugEnabled())" within JackRabbit. When using a Model 2 deployment with the JackRabbit Jars within Tomcat common/lib be aware that you need to explicitly ensure that logging is disabled (even though I'm not seeing debug in any logs). So by adding a log4j.xml to Tomcat common/classes with a <root> appender set to WARN this bottle neck has improved. releaseSession() is now 1.7% of CPU time instead of 11.4%. My comment on pooling sessions still stands though. Regards, Shaun. -----Original Message----- From: Shaun Barriball [mailto:[EMAIL PROTECTED] Sent: 27 March 2007 11:06 To: [email protected] Subject: Profiling shows Session management to be a hotspot - session pooling etc Hi all, We're currently CPU profiling an application which uses the SessionInView pattern to create a new JCR session (with JackRabbit) for each request. Profiling shows that around: - 11.4% of the CPU time is in releaseSession(). In particular around 5% of this is in ItemManager.evictItem(). - 0.08% of the CPU time is in getSession() For each request the application is just reading a set of nodes (upto around 100) to generate a web page. We're using JackRabbit 1.2.1 with Oracle. Any recommendations for how to resolve this overhead? - should we consider pooling sessions? - any way to optimise the session usage given the nodes are all read-only? All help appreciated. Regards, Shaun. ___________________________________________________________ All New Yahoo! Mail Tired of [EMAIL PROTECTED]@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html
