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?

Garris

May I suggest you to test the two approaches in your specific case and then compare the results ? – Angioma

@Stephan: This will require significant time to implement each method and test it. – Garris

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.

Muddleheaded

Thanks #Peter for very helpful answer. However, it difficult for me to understand how come MQ that use persistence (write to Hard disk) like yours, perform better than in-memeory MQ like ZeroMQ. – Garris

The ZeroMQ still uses system calls and these take time. esp if you add the delay across the kernel which is about 10 - 30 micro-seconds. By sharing a memory mapped file between processes, a message can pass from one process to another without a system call or involving the kernel. Some system calls have to be made to grow the file, but this is once every 128 MB by default. – Muddleheaded

Thanks ... more more questions please, I understand if I use plain Java socket, I could do serialization using ObjectInputStream-ObjectOutputStream. if this is case, why still people go to Java RMI. – Garris

With RMI or RPC you to make a call to a remote object. This means you can call rmiObject.method(a, b, 125); as if it were local to you. If you pass just an object, you still have to decide what to do with it. – Muddleheaded

Answer 2

If you are developing server application try to consider ZeroMQ. It has great performance, allow to build interprocess communication easier, allow to build asynchronous API.

ZeroMQ declare fantastic performance with InterProcess communication. Even better than TCP sounds great. We are consider this solution for our clusterisation schema.

Pieter Hintjens give the great answer for performance comparison between different Message Broker.

Avogadro