jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: Never Mind - Solved it myself Re: Introduction followed by Dumb, Obvious Developer Question
Date Mon, 07 Feb 2005 18:20:47 GMT
hi chuck,

thanks for sharing all the interesting information.

> We will have plenty of writes.  Likely between 10-20% writes overall.  We
> may end up storing things like chat messages in JCR.  We will have
> applications that store material in properties, and place observers on
> changes in content to provide real-time interactions for things like chat.
cool, sounds like a perfect match for a fully jcr compliant repository.

> If this is something that is not so good for JR, we should know that.  Make
> sure to separate the API issues from the implementation issues - we can add
> our own implementation to address performance issues.  
> If we picked JCR/JR, we would not put it into production until June.
of course the JCR as API itself has been designed to handle exactly
applications like the one you describe. with respect to jackrabbit
as the implementation believe that with a decent persistence 
manager you should be in the clear. as you may have picked up 
in this list a number of people have already conducted load tests
(mostly writing). i personally find the performance more than satisfactory: 
for example the "1-million-nodes-test" was not a very big hurdle for 
jackrabbit itself and was completed in less than an hour. 
yesterday we tested an mp3 library import of 1gb which 
was completed less than 6 minutes on a single cpu intel box to
test the blob behaviour.

to sum it up from my perspective:

1) jcr is specifically designed to handle exactly what you describe.
i think sakai could be a perfect jcr showcase.

2) jackrabbit's design should also supports the metrics you describe.
you may have to tweak the persistence managers (maybe not even), 
and maybe configure the search index properly. of course the
"content-design" (nodetypes) may have an impact too.

> One early medium application of our software (current version at University
> of Michigan) is 20,000 users, 100GB, 700 simultaneous users.  This is in
> daily and continuous production.  Our next large deployment is Indiana
> University which will likely be 500GB+, 100,000 users, 1500+ simultaneous
> users.  We also expect 20-100 smaller installations with 100-5000 users
> within a year.
> We do performance testing as a matter of course, and will only put stress on
> the implementation when we are confident.
i would be very interested in conducting those tests, maybe a generic
opensource "jcr-content-repository-load-test" could be the result of this 

> > with respect to the hierarchical authorization, i would certainly be
> > interested to find out if the "soon-to-come" built-in native jackrabbit
> > authorization is going to suit your needs, both functionality and
> > performance-wise.
> If we get started, our implementations will be done in public and
> open-source from their first lines of code.  I look forward to some good
> native JR implementations because they can bootstrap our process quite a
> bit.  It is much better to start with something working and speed it up.
> Our entire project is Jakarta-style license so we can only include other
> Jakarta-style licensed material in our distribution.

it really sounds like this could be the perfect jcr & jackrabbit 
showcase, let me assure at least from my end that you have 
my full support and let me know if there is anything that we can 
do to help your progress...


View raw message