Is there any point in using Netty with Disruptor performance-wise?

Question

I am building a simple reactive server which should consume incoming protobuf/protostuff messages from multiple clients, execute some business logic on them and possibly send fire-and-forget messages to other consumers. I want to implement transport and decoding part in Netty. My question is: is there any point on publishing decoded messages to the Disruptor's ring buffer performance-wise or the extra performance offered by Disruptor would be negated by internal Netty scheduling? Should I provide Netty with two threads (one for "accept" and other for "connect" group) or just one is better? Maybe, I should just split messages by length field in Netty's handlers, and execute decoding in Disruptor's ones?

Patsy

Answer 1

Depends ;)

The disruptor allows you to decouple various different actions, and potentially perform them in parallel. So the question is how expensive is your business logic and how bursty is your workload? The Disruptor is used to transfer data between threads, specifically threads which are potentially running at different message rates. I.e. it allows the producing thread to produce a burst of messages while the consuming thread is busy handling the last message.

For instance if you also wanted to persist your message to database as well as sending the result onwards you could publish the message to a "outbound" ringbuffer and have your netty code consume from that as well as a DB persister.

The less time you spend doing things in Netty's eventloop the more clients you can cope with, or larger messages volumes at the transport level.

Incubator

Thanks! It seems Disruptor would fit there since handling message bursts and journalizing are important part. – Patsy