jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lee Mallabone <lee.mallab...@transactgroup.net>
Subject Re: Performance
Date Thu, 13 Oct 2005 08:48:45 GMT

This should definitely go in the Jackrabbit wiki imho.

Perhaps as a new node, 'getting the best performance out of Jackrabbit', or 
something similar?


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

View raw message