Hi, On Fri, Feb 6, 2009 at 2:07 AM, MARTINEZ Antonio <[email protected]> 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. BR, Jukka Zitting
