Hi Alex, next week I'm out of the office. After that I will be able to run the tests again and report the results.
Arthur > -----Original Message----- > From: Alex Popescu [mailto:[EMAIL PROTECTED] > Sent: Friday, October 20, 2006 6:15 PM > To: [email protected] > Subject: Re: JackRabbit performance and scalability > > 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.getEffectiveNod > > > eTyp > > > e(NodeTypeRegistry.java:384) > > > - waiting to lock <0xb38677c8> (a > > > org.apache.jackrabbit.core.nodetype.NodeTypeRegistry) > > > at > > > > org.apache.jackrabbit.core.NodeImpl.getEffectiveNodeType(NodeImpl.ja > > > va: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.ja > > > va: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 > > > > >
