Mailing-List: contact commits-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Apache Wiki <wikidiffs@apache.org>
To: jackrabbit-commits@incubator.apache.org
Date: Wed, 29 Mar 2006 21:56:10 -0000
Message-ID: <20060329215610.29936.12541@ajax.apache.org>
Subject: [Jackrabbit Wiki] Update of "CommentsAboutPerformance" by RoyFielding

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 RoyFielding:
http://wiki.apache.org/jackrabbit/CommentsAboutPerformance

The comment on the change is:
format and wording

------------------------------------------------------------------------------
- jackrabbit works fast and was tested with several millions of items of real-life data and depending on the persistence manager used little to no performance degradation was noticed. see http://article.gmane.org/gmane.comp.apache.jackrabbit.devel/3977.
+ == Experience Reports ==
  
- Bellow there are a few comments about some issues that might affect the performance.
+ Apache Jackrabbit works fast and was tested with several millions of items of real-life data and, depending on the persistence manager, little to no performance degradation was noticed. See [http://article.gmane.org/gmane.comp.apache.jackrabbit.devel/3977 email].
  
- 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.
+ == Some issues that might effect performance ==
  
- 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.
+ === Tree Structure ===
  
- 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.
+ 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 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.
+ === 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.
+ 
+ === 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.
+ 
+ === 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.
+