jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu" <the.mindstorm.mailingl...@gmail.com>
Subject Re: JackRabbit performance and scalability
Date Thu, 19 Oct 2006 14:50:52 GMT
On 10/19/06, Arthur Meyer <arthurm@gx.nl> wrote:
> 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.
>

Is this happening with a flat node structure or is it always happening?

> 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.
>

This seems a bit dangerous, but I agree that it makes sense to have it
externally configurable.

> 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.
>

At first glance this looks bad :-(.

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

It depends what deployment architecture you plan to use. I would like
to hear more about what your intentions are and what you plan to
build.

./alex
--
.w( the_mindstorm )p.

PS: feel free to send email me privately if the information are
confidential: alexandru[dot]popescu[at]evolva[dot]ro

> 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