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.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:[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/
> >
> >
> >
