jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jackrabbit Wiki] Update of "CommentsAboutPerformance" by edgarpoce
Date Thu, 19 Jan 2006 02:18:57 GMT
Dear Wiki user,

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

The following page has been changed by edgarpoce:
http://wiki.apache.org/jackrabbit/CommentsAboutPerformance

New page:
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 node references. The problem described above also affects node references, i.e.
adding a reference to a highly referenced node will be slower each time. IMHO this problem
prevents a very common use case, i.e. tagging.

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.

Mime
View raw message