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

I'm gathering some data about the difference in performance between a JVM method call and a remote method call using a binary protocol (in other words, not SOAP). I am developing a framework in which a method call may be local or remote at the discretion of the framework, and I'm wondering at what point it's "worth it" to evaluate the method remotely, either on a much faster server or on a compute grid of some kind. I know that a remote call is going to be much, much slower, so I'm mostly interested in understanding the order-of-magnitude differnce. Is it 10 times slower, or 100, or 1,000? Does anyone have any 开发者_如何学编程data on this? I'll write my own benchmarks if necessary, but I'm hoping to re-use some existing knowledge. Thanks!

---

Having developed a low latency RMI (~20 micro-seconds min) it is still 1000x slower than a direct call. If you use plain Java RMI, (~500 micro-seconds min) it can be 25,000x slower.

NOTE: This is only a very rough estimate to give you a general idea of the difference you might see. There are many complex factors which could change these numbers dramatically. Depending on what the method does, the difference could be much lower, esp if you perform RMI to the same process, if the network is relatively slow the difference could be much larger.

Additionally, even when there is a very large relative difference, it may be that it won't make much difference across your whole application.

---

To elaborate on my last comment...

Lets say you have a GUI which has to poll some data every second and it uses a background thread to do this. Lets say that using RMI takes 50 ms and the alternative is making a direct method call to a local copy of a distributed cache takes 0.0005 ms. That would appear to be an enormous difference, 100,000x. However, the RMI call could start 50 ms earlier, still poll every second, the difference to the user is next to nothing.

What could be much more important is when RMI compared with using another approach is much simpler (if its the right tool for the job)

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

---

It's impossible to answer your question precisely. The ratio of execution time will depends on factors like:

• The size / complexity of the parameters and return values that need to be serialized for the remote call.
• The execution time of the method itself
• The bandwidth / latency of the network connection

But in general, direct JVM method calls are very fast, any kind of of serialization coupled with network delay caused by RMI is going to add a significant overhead. Have a look at these numbers to give you a rough estimate of the overhead:

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

Apart from that, you'll need to benchmark.

One piece of advice - make sure you use a really good binary serialization library (avro, protocol buffers, kryo etc.) couple with a decent communications framework (e.g. Netty). These tools are far better than the standard Java serialisation/io facilities, and probably better than anything you can code yourself in a reasonable amount of time.

---

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

You distribute components so multiple clients can share them. If the sharing is what's important, it outweighs the speed hit.

Your break even point has to do with how valuable it is to share functionality, not method call speed.