jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Jackrabbit standalone through RMI
Date Fri, 06 Feb 2009 09:20:17 GMT

On Fri, Feb 6, 2009 at 2:07 AM, MARTINEZ Antonio
<Antonio.Martinez@alcatel-lucent.com> wrote:
> Could I get more information on the technical reasons why there is such
> a big performance gap ?

The main reason for the performance problem is the design of the RMI
layer. The layer optimizes for API coverage and correctness instead of
performance by mapping almost all JCR API calls to remote method
calls. And since JCR is a very fine-grained API (e.g. each property
access is a separate method call), this results in a large number of
network roundtrips even for simple operations.

> I would like to understand what would take to improve that.

By far the biggest performance improvement could be achieved by making
the granularity of the network calls coarser and caching the retrieved
information on the client side. For example, a getProperty() call
could also retrieve the (non-binary) value(s) of the property so that
a getValue() call on the retrieved property can be executed locally.
Or more notably, the return value of a getNode() call could contain
all the properties and child node references of a node to boost calls
like getProperties() and getNodes(). Of course the price of such
changes is increased complexity and potential cache coherence issues.

Currently the most active front on implementing faster JCR remoting is
the SPI over WebDAV layer that's currently being developed in the
Jackrabbit sandbox. Please join the dev@ list if you're interested in
participating in the development effort.


Jukka Zitting

View raw message