Most Efficient - Performance wise - for inter JVM communication

Question

I have a Java application that require communication between different process. Process could run in same JVM or different JVM, but runs on the same machine.

My application need to submit "messages" to another process (same or different JVM) and forgot about it. similar to messaging queue like IBM "MQ", but simple, and only use memory, no IO to hard disk for performance gains.

I'm not sure what is the best approach from Performance prescriptive.

• I wonder if RMI is efficient in terms of Performance, I think it require some overhead.
• What about TCP/IP socket using local host?

any other thought?

Answer 1

I wonder if RMI is efficient in terms of Performance, I think it require some overhead.

RMI is efficient for what it does. It does much more than most people need, but is usually more than faster enough. You should be able to get of the order of 1-3 K messages per second with a latency around 1 milli-second.

What about TCP/IP socket using local host?

That is always an option but with plain Java Serialization this will not be a lot faster than using RMI. How you do the serialization and deserialization is critical for high performance.

---

An important note is that much of the time is spent serializing and deserilizing the message, something most transports don't help you with, so if you want maximum performance you have to consider an efficient marshalling strategy. Most transport protocols only benchmark raw bytes.

Ironically if you are willing to use disk, it can be faster than TCP or UDP (like ZeroMQ) plus you get persistence for "free".

This library (I am the author) can perform millions of messages per second between processes with latency as low as 100 nano-second (350x lower than ZeroMQ) https://github.com/peter-lawrey/Java-Chronicle Advantages are

• ultra fast serialization and deserialization, something most transport benchmarks avoid including this as it often takes much longer than the transport costs.
• is that you can monitor what is happening between queues any time after the message was sent.
• replay all messages.
• the producer can be any amount of data ahead of your consumer to handle micro-burst gracefully up to the size of your disk space. e.g. the consumer can be TBs behind.
• supports replication over TCP.
• restart of either the consumer or producer is largely transparent.