Q. My XPath query is too slow.
A. Quotes from mailist regarding XPath query performance can be found here: http://www.nabble.com/Explanation-and-solutions-of-some-Jackrabbit-queries-regarding-performance-td15028655.html
Performance of XPath queries is much better with 1.5 snapshot.
Q. I have too many child nodes and performance goes down.
A. The current internal Jackrabbit design is optimized for small to medium sized child node sets, i.e. up to ~10k child nodes per node. Really large child node sets negatively affect write performance.
Please note that this is not a general issue of JCR but specific to Jackrabbit's current internal persistence strategy - independent from the fact if you use a normal persistence manager or a "bundle" persistence manager, albeit the latter one is recommended; see PersistenceManagerFAQ. Each node contains the references to all its child nodes. This is a design decision inside Jackrabbit to improve speed when using few child nodes. To improve performance, introduce some extra-levels to your content model. This also helps humans to explore the repository when using a browser tool. Typical solutions are to use some categories of the context of your data or date folders, such as "2009/01/09".
Q. I have many references to a single node and performance goes down.
A. The current Jackrabbit design is not optimized for many nodes referencing a single node, because for easy back-referencing in the JCR API all those references are stored in the target node. Please note that many people don't recommend references in a content model anyway - see for example DavidsModel, rule #5.