This should definitely go in the Jackrabbit wiki imho. Perhaps as a new node, 'getting the best performance out of Jackrabbit', or something similar?
Lee. On Wednesday 12 October 2005 20:44, Edgar Poce wrote: > hi > > I haven't used jackrabbit with a huge amount of data yet but I did > run some tests and have some impressions I'd like to share, hopefully > someone will correct me if I'm misleading you. > > In most cases I agree with David and Marcel, who pointed that > jackrabbit doesn't seem to affected by the number of nodes. However, I > think that in order to maintain the performance you should take into > account some considerations on the usage that might affect it > seriously. > > Regarding the tree structure. Since each parent holds references to > its children each time you add a child the parent becomes heavier. It > causes a degradation in performance for write operations according to > the number of children. I think it's better to use a deep hierarchy > rather than a flat structure. I would recommend you to do some testing > to establish the limits that suits your needs. > > Regarding the session handling. A transient item storage is bound to > each session. The transient storage contains its own cache of nodes > that are connected to the underlying persistent storage. The thing is > that each time a node is modified, all the cached transient nodes are > notified. Therefore the more open sessions you have the more expensive > the write operation will be. I think you should try each session to > perform write operations on nodes which are not under heavy load from > other sessions. e.g. I think it's good practice to avoid write > operations in the root node if the repository is to be accessed by a > high number of sessions. I also think that it's a good practice to > share a single anonymous session for read only access if possible, it > would reduce the time that write actions will take. > > Regarding concurrency. Currently jackrabbit lacks fine grained locking > for write operations. So, if the repository will be under heavy load I > would consider an approach like the one used in Magnolia, I'm not sure > if they still use it but the last time I checked they had a repository > for authoring and another for publishing. > > br, > edgar >
