jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darren Hartford" <dhartf...@ghsinc.com>
Subject RE: Working with JCR in highly concurrent applications
Date Wed, 20 Sep 2006 20:14:32 GMT
I mis-spoke, I meant hardware/jvm limitation.  JVM tuning may assist as
much as code changes.
-D 

> -----Original Message-----
> From: Darren Hartford [mailto:dhartford@ghsinc.com] 
> Sent: Wednesday, September 20, 2006 4:09 PM
> To: users@jackrabbit.apache.org
> Subject: RE: Working with JCR in highly concurrent applications
> 
> Hi Alenadru,
> Could you actually be hitting a hardware limitation versus 
> software?  I tried to follow this thread back but do not see 
> the base hardware used.
> 
> In my small experience, once you have between 5-20 concurrent 
> threads on one processor (specifically regarding java, not 
> C/C++), you may start running into bottlenecks, and if you 
> are pushing towards 100 concurrent threads on one processor, 
> that may be more of the problem.  My experience wasn't 
> necessarily in this scope, but something to consider 
> regarding java concurrent threads.
> 
> -D
> 
> > 
> > 1/
> > NodeImpl.getProperty 31200calls 75343ms => PersistenceManager.load 
> > 312calls 609 ms
> > 
> > 2/
> > NodeImpl.getProperty 90800calls 85140ms => PersistenceManager.load 
> > 104calls 234ms
> > 
> > > >
> > > > I have tried 2 different approaches and unfortunately both are 
> > > > degrading when used in this concurrent environment. And 
> I am not 
> > > > talking about a few hundred concurrent threads: I have 
> tested it 
> > > > with 50, respectively 100 concurrent threads.
> > > >
> 

Mime
View raw message