jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Huber <shub...@jahia.com>
Subject Re: Scalability/Clustering
Date Fri, 08 Jul 2005 08:56:14 GMT
David Nuescheler wrote:

>we just recently ran a test using jackrabbit and cqfs
>populating roughly 5m items (~500k nodes) and
>even without using an rdbms back end we did not
>run into issues. the performance of the persistence layer 
>degraded over time though.
Don't you mean you got good performance because you were NOT using a 
database ? Although I've been a proponent of DB storage, I also know 
that there will always be an overhead compared to raw file access. There 
are other advantages though (as you've summarized here : 

:) )

>>Are there any efforts to make jackrabbit clustered for a load sharing
>>scenario (no session failover at repository layer) ?
>i think there are a couple of caches that need to be made 
>clusterable (or at least pluggable) in the jackrabbit core for 
>that to happen efficiently, it has to be done very carefully, 
>but it should not be to much work i think.
>this is definitely on the roadmap and investigations into that
>direction have already happend.
 From what I have seen making the cache implementation pluggeable would 
be a good necessary first step. It then becomes possible to use OSCache, 
JBossTreeCache or Tangosol Coherence that all handle clustered caches.

>>- implementing/extending an ORM Layer (Hibernate with shared caching for
>>  performance). The persistence implementation should be aware of the
>>  node types and allow a type specific mapping to tables. So we can map
>>  nodetypes with many instances to own tables while maintaining
>>  flexibility for new "simple" nodetypes.
One quick note about the current ORM implementation. The current 
implementation that I've worked on with Jackrabbit can be improved. Feel 
free to have a look and contribute ! But what David is saying is true : 
for performance, the higher you can cache, the better !

  Serge Huber.

View raw message