HI guys, 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 https://github.com/franz1981/activemq-artemis/tree/asyncio_disruptor 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 :) Cheer, Franz -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
