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

i building simple reactive server should consume incoming protobuf/protostuff messages multiple clients, execute business logic on them , possibly send fire-and-forget messages other consumers. want implement transport , decoding part in netty. question is: there point on publishing decoded messages disruptor's ring buffer performance-wise or performance offered disruptor negated internal netty scheduling? should provide netty 2 threads (one "accept" , other "connect" group) or 1 better? maybe, should split messages length field in netty's handlers, , execute decoding in disruptor's ones?

depends ;)

the disruptor allows decouple various different actions, , potentially perform them in parallel. question how expensive business logic , how bursty workload? disruptor used transfer data between threads, threads potentially running @ different message rates. i.e. allows producing thread produce burst of messages while consuming thread busy handling last message.

for instance if wanted persist message database sending result onwards publish message "outbound" ringbuffer , have netty code consume db persister.

the less time spend doing things in netty's eventloop more clients can cope with, or larger messages volumes @ transport level.