I have seen the question: Communication between two separate Java desktop applications (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.
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 to be more coarse-grained, and
looking at ways to turn synchronous interactions into asynchronous interactions; e.g. using message based rather than RPC based technologies.
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.
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.
Is it daft to think that RMI/JGroups on the same physical machine will be slow?
If your machine is decent probably yes :) If you're running on a machine with tons of processes eating CPU etc then things might be different. As always the best way to find out if you would experience the same thing as me is to test it.
The following is the time in milliseconds taken using nanoTime in the same JVM to send the string "123" using rmi and on the server concat it with "abc" to get "123abc" and return it.
Cold JVM: Approximately 0.25 millisecond latency
0.250344
0.262695
0.241540
0.282461
0.301057
0.307938
0.282102
Warm JVM: Approx 0.07 millisecond latency.
0.87916
0.72474
0.73399
0.64692
0.62488
0.59958
0.59814
0.66389
So you would be well within 1 millisecond if the RMI server and client is running locally.
来源：https://stackoverflow.com/questions/2068958/how-fast-might-rmi-be