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 marcel.reutegger@gmx.net
 designates 213.165.64.20 as permitted sender)
Message-ID: <45379597.1090606@gmx.net>
Date: Thu, 19 Oct 2006 17:11:19 +0200
From: Marcel Reutegger <marcel.reutegger@gmx.net>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: dev@jackrabbit.apache.org
Subject: Re: JackRabbit performance and scalability
References: 
 <34B0CDC6176518459F3A96E8C09196B8047E259D@darth-vader.nijmegen.gx.nl>
In-Reply-To: 
 <34B0CDC6176518459F3A96E8C09196B8047E259D@darth-vader.nijmegen.gx.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Arthur,

thanks a lot for investigating the performance of jackrabbit in such detail.

you seem to have quite a good understanding of the internals of jackrabbit. Can 
I encourage you to propose patches for the hot spots you identified?

we will be happy to review them and incorporate the changes if performance can 
be improved with them.

regards
  marcel


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