1

Let there be 5 producer threads, and 1 queue. It seems like I have 2 options:

  • create an appender for each producer thread, append concurrently and let chronicle queue deal with synchronization (enable double-buffereing?)

  • synchronize the 5 producer threads first (lockfree mechanism e.g. disruptor), create 1 extra thread with 1 appender that writes into chronicle queue

Why this question?

I had the initial impression that writing to a chronicle queue is lock-free and should therefore be really fast. But github documentation mentioned multiple times there is a write lock that serializes concurrent writes. So I wonder if a lockfree disruptor placed in front of the chronicle queue would increase performance?

ccnlui
  • 91
  • 5

1 Answers1

2

What you suggest can improve the writer's performance, esp if you have an expensive serialization/marshalling strategy. However, if you are writing to a real disk, you will find the performance of the drive is possibly your biggest issue. (Even a fast NVMe drive) You might find the time to read the data is worse.

Let's say you spend 1 microsecond writing a 512-byte message, and you are writing at 200K/s messages. This means that your 80%ile will be an extra 1 us waiting for the queue due to contention. However, you will be writing 360 GB/h as will very quickly fill a fast NVMe drive. If instead, you have a relatively low volume of 20K/s messages, you are increasing your 98%ile latency by 1 us.

In short, if write contention is a problem, your drive is probably a much bigger problem. Adding a disruptor could help the writer, but it will delay the read time of every message.

I recommend building a latency benchmark for a realistic throughput first. You can double buffer the data yourself by writing first to a Wire and only copying the bytes while holding the lock.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • I can understand the argument but I don't follow the numbers. How does 5 producers writing at 200K/s, where each write takes 1us, leads to an extra 1us at p80 latency? I can see each producer tries to write every 5us. How does the extra 1us at p80 latency follow logically? – ccnlui Apr 19 '22 at 18:03
  • 1
    @ccnlui About 20% of the time, the queue will already be busy writing a message for another thread. – Peter Lawrey Apr 20 '22 at 10:07