Hi, the structure of the nodes in the repository during our test was relatively flat. Should this matter for the performance of queries?
We would like to have an architecture without a single point of failure, that is as scalable if possible. Using one repository server that handles all requests of other applications over RMI doesn't match this requirement. Arthur > -----Original Message----- > From: Alexandru Popescu [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 19, 2006 4:51 PM > To: dev@jackrabbit.apache.org > Subject: Re: JackRabbit performance and scalability > > On 10/19/06, Arthur Meyer <[EMAIL PROTECTED]> 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.getEffectiveNodeT > > yp > > 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:[EMAIL PROTECTED] > > > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > > > > > > Wijchenseweg 111 > > > > 6538 SW Nijmegen > > > > http://www.gx.nl/ > > > > > > > > > > > > > >
