jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Popescu" <the.mindstorm.mailingl...@gmail.com>
Subject Re: JackRabbit performance and scalability
Date Fri, 20 Oct 2006 16:14:33 GMT
It looks like the usage of Lucene 2.0 is already possible:
http://issues.apache.org/jira/browse/JCR-352 (see provided patches).

I am quite curious if this is solving the problems Arthur is
mentioning in this thread.

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

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

Mime
View raw message