I tested Chronicle Queue 3.2.1 with three disk types on an i7 MacBook
Air -- in part to try and answer for myself the question in Peter Lawrey's FAQ
about whether the disk write included in Chronicle was consequential.
I used the ExampleReadWriteMain.java for this purpose, and pointed it
at:

• NAS HDD - expected to be slow, and was -- about 25 seconds to write and read 5,000,000 entries
• local SSD - 5.7 seconds for the same
• RAM disk - 5.4 seconds for the same

The last one surprised me. I did not expect close to parity between
RAM disk and SSD. If it's true it supports the argument that
developers should just pocket the (substantial) benefit of the
replayable journal and not worry about its latency impact so long as
they target a good SSD.

I can think of three explanations:

• Chronicle's maximum performance is limited by something other than the disk write.
• The benchmark has too much overhead, e.g. from the Random call, overwhelming the difference
• The difference between RAM disk and SSD is not as big as I had thought.

XBench clocks my laptop's uncached sequential writes at 876MB/second
for RAM disk and 421MB/second for the Samsung SSD. But what's really
interesting is the difference in performance based on block size. For
4K blocks the RAM disk is 2x faster, which is maybe close enough that
if disk is not that big a fraction of the time spent it's not going to
result in a dramatic difference. But for 256K blocks the RAM disk is
10x faster than the SSD.

So the answer to whether you could boost Chronicle Queue with a RAM
disk might depend on how large the serialized messages are. The bigger
the messages, the more you'd be better off journaling to RAM and then
shipping the log to some other persistent store -- though you'd have
to test it.

As part of this I found a very nice RevoDrive SSD that is 3x faster than mine.