Lock-free Journal Batching Buffer
in the last weekends I'm doing some experiment to improve efficency of the
TimedBuffer by implementing a lock-free version of it.
I have measured that most of the time (with very fast disks) the TimedBuffer
is just consuming CPU while not doing I/O
but signaling/awaiting due to some write to be notified/persisted: just
cutting that time to 0 (especially with many cores servers) means much
better latencies and throughput.
I have implemented a POC here
using the disruptor to provide efficient sys-calls/IOPS smart batching and
allow scaling and low latency
writes when VERY fast disks are employed.
The <journal-buffer-timeout>TIMEOUT</journal-buffer-timeout> configuration
has a very different
meaning from TimedBuffer ie the time in nanoseconds the buffer it is
expected to sleep when no new messagges are arriving.
TLDR if you want to maximize the disk, putting it as low as 1 or just equals
to the RTT of your network (broker<->clients) will be enough.
ATM no CPU saving mechanism has been employed to save cycles from being
burnt while waiting, but
in a final version it can be implemented too (eg after X second of
inactivity, go to sleep for real).
That means to not be scared by very HIGH cpu usage: that's part of the work
to do on it.
The main benefit of it is that now you can choose to not being contended on
kernel space (that's what a Semaphore::acquire/release does on TimedBuffer)
and the initial results are very promising.
If anyone is interested to know some numbers/details or just share the
experience by trying it, please go ahead :)
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html