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 RoyFielding
Date Wed, 29 Mar 2006 21:56:10 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 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.
+ 

Mime
View raw message