Performance issue with RMI

[Damiano Albani <da...@gmail.com>]

Hello,

I've been using the Jackrabbit RMI module to provide access to the Oak
repository to external applications, in a sort of microservice
architectured solution.
It functionally fulfills my needs so far, but the performance doesn't seem
to be very good: JCR operations over RMI take quite some time to execute
apparently.
For example, fetching 20 nodes by path and retrieving their properties can
take ~ 0.5 s in my scenario.
Both the RMI server and client reside in the same local network — or even
local machine actually, given that they are Docker containers on the same
host.
I've recorded the network traffic with Wireshark and I didn't see any weird
pattern, only lots of RMI "Call" and "ReturnData" entries.
What I did see which caught my attention is that the "ReturnData" packets
often contain the classpath with a list of all the JAR files loaded by the
RMI server!?!
I have no idea if that's a standard RMI behavior, but it makes RMI
responses quite large (20+ KB).

So, I am wondering, is that the normal performance / behavior to expect
with the Jackrabbit RMI module? Or would that lie on a misconfiguration or
bad performance of my Oak instance altogether?

For the record, I'm using Oak 1.10.2 with JDK 11 on Linux (MongoDB node
store).

Thanks!

-- 
Damiano Albani

Re: Performance issue with RMI

[Damiano Albani <da...@gmail.com>]

For the record, should someone ever run into the same issue, the large RMI
packets were due to a Java class loader thing, as I explained on
https://stackoverflow.com/questions/54664502/huge-return-data-using-spring-rmi-rmiserviceexporter-and-rmiproxyfactorybean/55690688#55690688
.
For the rest, the performance of the RMI communication channel seems
"normal" (~ 1 ms per packet) but given the overall number of methods called
/ packets exchanged, it it thus quite "slow", compared to code running in
the same JVM.
I'll try if remoting with DavEx is any better in my case.
I also found a reference to a so-called SPI RMI solution, but it seems to
be old code which is not maintained:
https://wiki.apache.org/jackrabbit/HowtoSpi2Rmi

On Sun, Apr 14, 2019 at 11:42 PM Damiano Albani <da...@gmail.com>
wrote:

> Hello,
>
> I've been using the Jackrabbit RMI module to provide access to the Oak
> repository to external applications, in a sort of microservice
> architectured solution.
> It functionally fulfills my needs so far, but the performance doesn't seem
> to be very good: JCR operations over RMI take quite some time to execute
> apparently.
> For example, fetching 20 nodes by path and retrieving their properties can
> take ~ 0.5 s in my scenario.
> Both the RMI server and client reside in the same local network — or even
> local machine actually, given that they are Docker containers on the same
> host.
> I've recorded the network traffic with Wireshark and I didn't see any
> weird pattern, only lots of RMI "Call" and "ReturnData" entries.
> What I did see which caught my attention is that the "ReturnData" packets
> often contain the classpath with a list of all the JAR files loaded by the
> RMI server!?!
> I have no idea if that's a standard RMI behavior, but it makes RMI
> responses quite large (20+ KB).
>
> So, I am wondering, is that the normal performance / behavior to expect
> with the Jackrabbit RMI module? Or would that lie on a misconfiguration or
> bad performance of my Oak instance altogether?
>
> For the record, I'm using Oak 1.10.2 with JDK 11 on Linux (MongoDB node
> store).
>
> Thanks!
>
> --
> Damiano Albani
>


-- 
Damiano Albani