jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting ...@yukatan.fi>
Subject JCR-RMI RangeIterator performance
Date Fri, 15 Apr 2005 16:36:12 GMT

[Moving a private discussion to the -dev list.]

Tobias Strasser:
 > one question: the RemoteNode.getNodes() returns an array of
 > RemoteNodes. I not sure, who this performs for a large number of child
 > nodes. The RangeIterator was introduced especially to circumvent such
 > issues. maybe the RemoteNode should make use of the RangeIterator
 > aswell?

Felix Meschberger:
> Re RangeIterators: Maybe this is the easiest and most straight forward 
> way to transfer the RangeIterator stuff over the net... I think, it 
> should probably be possible to have some sort of a RemoteRangeIterator ? 
> Jukka is there a reason for not having one ? I agree with Tobias' 
> concern on performance, actually I seem to hit at them :-)

My design goal for JCR-RMI was to keep it as simple and straightforward 
as possible while trying to minimize network traffic, especially the 
amount of round-trips to the server. In many cases reducing server 
round-trips requires separate caching, with associated validity 
problems, but RangeIterators and Values can normally be cached without 
problems (AFAIK).

I think the iterators-as-arrays design decision causes problems only 
when there are thousands of iterated items, causing noticeable network 
bandwidth, serialization/deserialization, and object instantiation 
delays. I believe that a normal JCR client always iterates through all 
or most of the received iterator elements, thus negating the problem of 
transmmitting too much data.

If this is a problem, it would be easy to create separate 
RemoteRangeIterator interfaces as suggested by Felix. There could be an 
optional  ClientRepository attribute that can be used for selecting the 
desired iterator behaviour on the client side. Even better, the server 
could dynamically decide whether to return an array or an iterator based 
on the size of the underlying data set.

Anyhow, I have not yet really been focusing on performance of JCR-RMI. 
My initial plan was to introduce a separate general caching layer on top 
of JCR-RMI as an optional performance booster, but so far I haven't had 
time to do anything substantial with that idea.


Jukka Zitting

View raw message