Hi,
Thomas Duffey wrote:
The "Repository Server HOWTO" warns that the current implementation
has serious performance issues. Does anyone know just how serious
these issues and if anyone is working on improvements? If this model
is not ready for prime time then how are people using Jackrabbit in
clustered application server environments? I understand these are
difficult questions to answer but any insight or advice on using
Jackrabbit as a repository server will help!
The JCR-RMI layer that the warning on the HOWTO page refers to is currently
designed for simplicity instead of performance. The current
implementation maps
almost all API calls to remote method invocations, which results in
many network
roundtrips for even relatively simple repository operations. Simple
optimizations like streaming all query results in a single operation
would go a
long way to improving the performance. Another more advanced
optimization would
be to host the entire transient session state at the client side and only
sending changes over the network when the save() method is invoked.
I've recently started focusing more on the performance and resource issues of
JCR-RMI, but I haven't really made much visible progress yet as I've been
somewhat occupied by other work. So far I've done some initial benchmarks and
have a pretty good picture of the worst bottlenecks. I'm hoping to have solved
the biggest performance issues by the time the Jackrabbit 1.0 release is made.
BR,
Jukka Zitting
