What is the performance difference between a JVM method call and a remote call?

Question

I am collecting some data on the performance difference between a JVM method call and a remote method call using a binary protocol (in other words, not SOAP). I am developing a structure in which a method call can be local or remote at the discretion of the framework, and I wonder at what point it is "worth" to evaluate the method remotely, either on a much faster server, or to calculate some kind of grid. I know that a remote call will be much, much slower, so I am most interested in understanding the order of magnitude. Is it 10 times slower, or 100 or 1000? Does anyone have any data on this? If necessary, I will write my own tests, but I hope to reuse some existing knowledge. Thanks!

Answer 1

Having developed RMI with a low latency (~ 20 microseconds min), it is still 1000 times slower than a direct call. If you use simple Java RMI, (~ 500 microseconds min), it can be 25,000 times slower.

NOTE. This is a very rough estimate, which will give you a general idea of ​​the difference that you can see. There are many complex factors that can significantly change these numbers. Depending on what this method does, the difference can be much lower: esp, if you are running RMI in the same process, if the network is relatively slow, the difference can be much larger.

In addition, even if there is a very large relative difference, it may not make much difference for your entire application.

---

Think over my last comment ...

Suppose you have a GUI that needs to poll some data every second, and a background thread is used for this. Assume that using RMI takes 50 ms, and the alternative makes a direct call to the local copy method of the distributed cache takes 0,0005 ms. It would seem that this is a huge difference, 100 000x. However, the RMI call may start 50 ms earlier, still polling every second, the difference with the user is almost nothing.

Which can be much more important when RMI compared to using another approach is much simpler (if its the right tool for the job)

An alternative to using RMI is to use JMS. It best depends on your situation.

Answer 2

It is not possible to accurately answer your question. The runtime ratio will depend on factors such as:

• The size / complexity of the parameters and return values ​​that must be serialized for the remote call.
• Method execution time
• Network Connection Bandwidth / Delay

But, in general, direct JVM method calls are very fast, any serialization combined with network latency caused by RMI will add significant overhead. Look at these numbers for a rough estimate of the overhead:

http://surana.wordpress.com/2009/01/01/numbers-everyone-should-know/

In addition, you need to navigate.

One tip: make sure you use a really good binary serialization library (avro, protocol buffers, cryos, etc.) that have a decent communications infrastructure (like Netty). These tools are much better than standard / io serialization tools for Java, and probably better than anything you can program yourself in a reasonable amount of time.

Answer 3

No one can tell you the answer, because the decision about whether to distribute is not speed. If that were the case, you would never make a distributed call, because it will always be slower than the same call made in memory.

You distribute the components so that they can be divided into several clients. If separation is important, it outweighs the speed.

Your break-even point is related to how valuable the sharing of functions is, not the speed of the method call.