Disruptor message bundler implementation
I recently implemented a DisruptorBundler, which uses LMAX Disruptor (3.3.4) as message bundler implementation, and compared it with TransferQueueBundler. The code is at [1].
The setup used mode=MULTI which is optimized for many producers (sender threads).
I used UPerf as test. Unfortunately, UPerf only measures throughput, but I’ll soon add latency and then re-test, so we have those numbers, too.
I varied the senders threads/node from 25 → 50 → 100 and compared TransferQueue to the 7 wait strategies available in Disruptor today.
The Disruptor bundler is way faster with the SleepingWait- and Yielding-WaitStrategies, however, they cause very high CPU usage. For instance, SleepingWaitStrategy used 320% of my 4 core mac (2014 model), even when the system was idle and no messages were sent!
The YieldingWaitStrategy was better, but still used ca. 180% even when the system was idle. When sampling with jvisualvm, the red bar caused by Disruptor dwarfed the other bars!
The other strategies were the same or slower than TransferQueueBundler.
I remember vaguely having read that Disruptor’s design requires only few threads to run best, so I might come back to it once we’ve reduced our thread usage.