Chronicle Queue unexpected latency

Question

I have been doing some performance testing on Chronicle queue and I am not getting the latency in the micro seconds that Chronicle claims I should. I have a single writer and reader setup. The writer writes the current time into the queue and the reader reads out of the queue and get the current time and does a diff the get the latency. I do this for a million messages and then take the average.

Code for my writer:

public class Client {
    public static void main(String[] args) {
    String path = "/dev/shm/queue";
    SingleChronicleQueue queue = SingleChronicleQueueBuilder.binary(path).build();
    ExcerptAppender appender = queue.acquireAppender();
    Scanner read = new Scanner(System.in);
    for (int i = 0;i<1;i++){

        for (int j=0;j<1000000;j++) {
            long time = System.nanoTime();
            appender.writeText(Long.toString(time));
        }
    }
    appender.writeText("end");
    }
}

My reader

public class Server {
    public static void main(String[] args) {
    String path = "/dev/shm/queue";
    SingleChronicleQueue queue = SingleChronicleQueueBuilder.binary(path).build();
    ExcerptTailer tailer = queue.createTailer();

    DescriptiveStatistics results = new DescriptiveStatistics();
    while (true) {
        String text = tailer.readText();
        if (text == null) {
            Jvm.pause(10);
        } else if (text.equals("end")) {
            System.out.println("Results: " + results.getMean() / 1000);
            break;
        }
        else {
            long cur = System.nanoTime();
            long recv = Long.parseLong(text);
            long diff = cur - recv;
            results.addValue(diff);
        }
    }
    }
}

I get latencies in the tens and sometime hundreds of milliseconds. Can any help me with this? I think I am doing something obviously wrong.

Most likely your writer is getting ahead of your reader as you are running as fast as possible. Try doing say 1 million per second with a busy loop yo wait until the next micro-second — Peter Lawrey, May 15 '17 at 06:19

score 1 · Answer 1 · answered May 15 '17 at 06:28

The delay is most likely real. If you write as fast as possible, the writer can be ahead of the reader showing an increasing delay the longer you run the test. Most messaging systems have flow control which slow the producer but this effect alters the test to look better. BTW You are not warming up the code though this shouldn't cause such large delays.

I suggest you try

adding a busy loop to the writer to limit it to one message per microsecond. Ie say 1 million per second.
busy wait on the reader or use Thread.yield (). I suggest using our Pauser.balanced()
try ignoring the first 20k or even 100k results to see after warm up and run the test for about 10 seconds or much more.
try not producing any garbage. You can append the long to a cleared/recycled StringBuilder or Bytes as text or write it as binary.

Chronicle Queue unexpected latency

1 Answers1