jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arthur Meyer" <arth...@gx.nl>
Subject RE: JackRabbit performance and scalability
Date Thu, 19 Oct 2006 13:08:08 GMT
Hi,

these are the most important issues we have encountered so far:

Increasing the number of nodes in the repository also has a big negative
effect on the performance of queries.
When we multiplied our content by four, our queries took about twice as
much time to execute.
Hopefully, Lucene 2.0 may have improvements here aswell.

The item state cache is limited and can't be configured as far is I
know.
Since loading node items from the database is relatively expensive, 
we would like to be able to cache as much as possible.

Node.isNodeType() calls cause monitor contention in a concurrent
environment. 
For example, if you use the getUUID() method on nodes a lot, this will
become a serious bottleneck. 
"http-18080-Processor8" daemon prio=1 tid=0x08571740 nid=0x79ca waiting
for monitor entry [0xa97f1000..0xa97f2eb0]
        at
org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.getEffectiveNodeTyp
e(NodeTypeRegistry.java:384)
        - waiting to lock <0xb38677c8> (a
org.apache.jackrabbit.core.nodetype.NodeTypeRegistry)
        at
org.apache.jackrabbit.core.NodeImpl.getEffectiveNodeType(NodeImpl.java:8
68)
        at
org.apache.jackrabbit.core.NodeImpl.isNodeType(NodeImpl.java:1245)
        at
org.apache.jackrabbit.core.NodeImpl.getUUID(NodeImpl.java:2802)

Further, the parsing of nodetype names seems to be a bottleneck in the
isNodeType() implementation
        at
org.apache.jackrabbit.name.NameFormat.parseIgnoreCache(NameFormat.java:2
52)
        at
org.apache.jackrabbit.name.NameFormat.parse(NameFormat.java:80)
        at
org.apache.jackrabbit.core.NodeImpl.isNodeType(NodeImpl.java:2552)

Similar monitor contention issues occur in the CachingNamespaceResolver
class.
Using the util.concurrent classes could help solving these issues.

Finally, we're also very interested in using jackrabbit in a clustered
environment. 

Arthur Meyer
 

> -----Original Message-----
> From: Alexandru Popescu [mailto:the.mindstorm.mailinglist@gmail.com] 
> Sent: Wednesday, October 18, 2006 10:35 AM
> To: dev@jackrabbit.apache.org
> Subject: Re: JackRabbit performance and scalability
> 
> On 10/18/06, Arthur Meyer <arthurm@gx.nl> wrote:
> > Hi,
> >
> > we have some performance and scalability issues using 
> JackRabbit which 
> > we would like to solve.
> >
> > We are very interested in cooperating to achieve better performance 
> > and are optionally willing to pay someone to help improving 
> > performance.
> >
> 
> Can you list the problems you have identified so far?
> 
> > Are more people interested in improving the performance and 
> > scalability of JackRabbit and is there a list of performance 
> > improvement options, like upgrading to Lucene 2.0?
> >
> 
> So, far the only "hot spot" I have identified as performing 
> quite bad in a highly concurrent environment is the querying 
> system. Indeed, Lucene 2.0 may have improved here, but as far 
> as I know there are quite a few changes in the Jackrabbit 
> core that needs to be done to allow this upgrade.
> 
> ./alex
> --
> .w( the_mindstorm )p.
> 
> 
> > Regards,
> > Arthur Meyer
> >
> >
> > Arthur Meyer
> > <GX> creative online development B.V.
> >
> > t: 024 - 3888 261
> > f: 024 - 3888 621
> > e: arthurm@gx.nl
> >
> > Wijchenseweg 111
> > 6538 SW Nijmegen
> > http://www.gx.nl/
> >
> >
> >

Mime
View raw message