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.
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.