[Jackrabbit Wiki] Update of "Performance" by MichaelDürig

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The "Performance" page has been changed by MichaelDürig.
http://wiki.apache.org/jackrabbit/Performance?action=diff&rev1=11&rev2=12

--------------------------------------------------

  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".
+ 
+ From Jackrabbit 2.2 on there are some utility classes in the org.apache.jackrabbit.flat package of the jcr-commons module for automatically arranging nodes in a B-Tree like manner while maintaining a flat view. See JCR-2688.   
  
  == 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, [[http://wiki.apache.org/jackrabbit/DavidsModel#head-ed794ec9f4f716b3e53548be6dd91b23e5dd3f3a|rule #5]].