Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (asf.osuosl.org: domain of
 the.mindstorm.mailinglist@gmail.com designates 66.249.92.175 as permitted
 sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=J0a82PBriAs/Diijg+zZLfRdODM68hqD5W0npPjJCLBbKzpU86vW45/TBXCFKkNOljQag7VaUV/ynscIccpAfckJZmhC1/MtedaTBLXbdZJN+sad3bPfHCo0VqDrd/gCOaRebZki0MY4KhZBDADKssv/JnrjVn0wYc7rA0o/bBQ=
Message-ID: <c6f400460610190750mbcee537vc2e2f3aaf6d8957b@mail.gmail.com>
Date: Thu, 19 Oct 2006 17:50:52 +0300
From: "Alexandru Popescu" <the.mindstorm.mailinglist@gmail.com>
To: dev@jackrabbit.apache.org
Subject: Re: JackRabbit performance and scalability
In-Reply-To: 
 <34B0CDC6176518459F3A96E8C09196B8047E259D@darth-vader.nijmegen.gx.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <c6f400460610180135h2561cc5fyda36e8fdbfafdacf@mail.gmail.com>
	 <34B0CDC6176518459F3A96E8C09196B8047E259D@darth-vader.nijmegen.gx.nl>

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