How Fast Might RMI Be?

Question

I have seen this question (answer: JGroups) and I'm thinking about implementing something with JavaGroups or straight RMI but speed is of the essence. I'm not sending large amounts of data around (content of MIDI Messages, so 3 bytes each, no more than say two messages every three milliseconds) and this will be all on the same machine. Is it daft to think that RMI/JGroups on the same physical machine will be slow?

(My thought is that I can't afford more than 1ms of latency, since I've already got some, but I'm not sure how to best talk about speed in this context.)

I guess my real question is: are there any options for interapp communication in Java that go through something FASTER than TCP/IP? I mean things already implemented in Java, not JNI possibilities that I'd need to implement :)

I know, don't optimize early and all that, but also better safe than sorry.

Answer 1

This benchmark is about two years old, but it shows that the only popular Java remoting solution faster than RMI is Hessian 2(which is still in beta I believe).

However if your messages are only in single digit bytes, using any remoting solution seems like overkill, especially if the processes are on the same machine. I'd recommend consolidating them into a single process if possible. You could also consider just using plain old Java sockets.

Answer 2

are there any options for interapp communication in Java that go through something FASTER than TCP/IP?

Not significantly ... AFAIK.

But I think you are thinking about this the wrong way. Assuming that you are moving small messages, the main performance killer will be the overheads of making a call rather than the speed at which bytes are moved. These overheads include such things as the time taken to make system calls, to switch process contexts on the client and server side, to process message packet headers within the kernel and to route packets. And any synchronous RPC-like interaction entails making a call an waiting for the reply; i.e. the app -> server -> round trip time.

The way to get greater throughput is to focus on the following:

• reducing the number of RPCs that the application requires; e.g. by combining them more coarse-grained, and

• looking at ways to turn synchronous interactions into asynchronous interactions; e.g. using message based rather than RPC based technologies.

Answer 3

If speed is of the essence, you should make the call in the same thread. You won't get as fast as this using a network.

However, assuming speed is not quite that important you can perform Java RMI calls in about 500 micro-seconds and using custom coded RPC you can make calls over loopback in about 24 micro-seconds. Even passing data between threads in the same JVM can take 8 micro-seconds.

You need to decide how much time you are willing to allow to place a network call. You also need to decide if the time to start the call is critical or the time to return a result. (Often the latter has double the overhead)

Note: I am talking micro-second here, not milli-seconds. I would ignore any options which take multiple milliseconds for your purposes.