Jukka Zitting wrote: > > > What does the troublesome query look like? > > BR, > > Jukka Zitting > >
Hi, The queries are fairly straight forward, for example: /jcr:root/mynode//element(*, my:nodetype) order by @myProp ascending. I then iterate through a hundred or so nodes from the resulting NodeIterator (which may contain many thousand results in total) and access various properties and child nodes. It this latter bit that is extremely slow the first time around. The slowness seems to be proportinal to the tital number of nodes in my query results rather than the number of operations I perform against the results. Subsequent runs are much faster, presumably due to Jackrabbit's in-memory caching. I've since read that XPath queries are not recommended for retrieving large sets of nodes, and that programmatic traversal of the repository is much faster. I'll refactor the code accordingly, but I can't believe that that's the reason my app is taking minutes to load rather than seconds. What's particualrly annoying is that that the during the first (non-cached) run the CPU utilisation bumbles along at 10%. So what's causing the bottleneck? MySQL doesn't seem to be running too hot and the only info I'm getting from Jackrabbit are some messages re cache effectiveness. -- View this message in context: http://www.nabble.com/Caching-performance-issue-%28urgent-help-required-please%21%29-tp23592190p23633390.html Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
