Just out of curiosity how many calls per second did you achieve using RMI and the redhat impl? I only tested CXF calls till now and wonder what difference the binary format makes.

Christian

On 16.02.2016 18:20, Johannes Utzig wrote:
Thank you for your swift response.
I see what you mean. I think r-OSGi (at least combined with zookeeper
discovery) isn't really meant to run between two instances on the same
machine.
However, since r-OSGi ended up killing my karaf instance quite a few times I
think this is probably not a transport we'd want to employ right now.

Instead I switched to ecf.generic.server which works out of the box.

I ran our simple benchmark which calls a remote service 1000 times with 5
parallel threads and compares the execution time with RMI (each call sends
and receives a string array).

ecf.generic.server seems to be roughly 10 times slower than RMI, but the
strange part is, with each invocation it becomes slower. Please see the test
output below:

karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 6838 milliseconds. Parallel level is
5
Test parallel RMI completed in 829 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 6188 milliseconds. Parallel level is
5
Test parallel RMI completed in 649 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 8024 milliseconds. Parallel level is
5
Test parallel RMI completed in 190 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 10415 milliseconds. Parallel level is
5
Test parallel RMI completed in 190 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 12628 milliseconds. Parallel level is
5
Test parallel RMI completed in 176 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 14125 milliseconds. Parallel level is
5
Test parallel RMI completed in 184 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 16330 milliseconds. Parallel level is
5
Test parallel RMI completed in 191 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 18014 milliseconds. Parallel level is
5
Test parallel RMI completed in 189 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 21011 milliseconds. Parallel level is
5
Test parallel RMI completed in 186 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 22741 milliseconds. Parallel level is
5
Test parallel RMI completed in 190 milliseconds. Parallel level is 5

This persists until I restart the karaf instance that provides the service.

We are looking for perfomance similar to RMI and the fabric implementation
was able to provide that.
Now to my understanding we could implement a distribution provider based on
the fabric code that could be used by ECF.
Unfortunately, I am a bit unsure on how to do this. I looked at
https://wiki.eclipse.org/Tutorial:_Creating_a_RESTful_Remote_Service_Provider
and a lot of additional documentation but so far I am still a bit unsure on
how to proceed or which is the minimal set of dependencies I would need.
I also noticed that the ECF artifacts on maven central are very outdated, so
I probably cannot use them to compile against. Are there plans to publish
up-to-date artifacts to central for easier consumption?

Would this serve as a mimimal example on how to implement a new TCP based
distribution provider, or should I use a different implementation as a
template?
https://github.com/eclipse/ecf/tree/master/providers/bundles/org.eclipse.ecf.provider.r_osgi/src/org/eclipse/ecf/internal/provider/r_osgi

Best regards,
Johannes



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Proposal-Lightweight-standalone-remote-OSGi-implementation-for-karaf-cellar-tp4045343p4045394.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Reply via email to