[zeromq-dev] Java NIO selector minimum possible latency

Julie Anderson julie.anderson.uk at gmail.com
Thu Aug 23 22:12:16 CEST 2012


I am doing some benchmarks with an optimized Java NIO selector on Linux
over loopback (

My test is very simple:

- One program sends an UDP packet to another program that echoes it back to
the sender and the round trip time is computed. The next packet is only
sent when the previous one is acked (when it returns). A proper warm up
with a couple of millions messages is conducted before the benchmark is
performed. The message has 13-bytes (not counting UDP headers).

For the round trip time I get the following results:

- Min time: 13 micros
- Avg time: 19 micros
- 75% percentile: 18,567 nanos
- 90% percentile: 18,789 nanos
- 99% percentile: 19,184 nanos
- 99.9% percentile: 19,264 nanos
- 99.99% percentile: 19,310 nanos
- 99.999% percentile: 19,322 nanos

But the catch here is that I am spinning 1 million messages.

If I spin only 10 messages I get very different results:

Min time: 41 micros
Avg time: 160 micros
75% percentile: 150,701 nanos
90% percentile: 155,274 nanos
99% percentile: 159,995 nanos
99.9% percentile: 159,995 nanos
99.99% percentile: 159,995 nanos
99.999% percentile: 159,995 nanos

Correct me if I am wrong, but I suspect that once we get the NIO selector
spinning the response times become optimum. However if we are sending
messages with a large enough interval between them, we pay the price of
waking up the selector.

If I play around with sending just a single message I get various times
between 150 and 250 micros.

So my questions for the community are:

1 - Is my minimum time of 13 micros with average of 19 micros optimum for
this round trip packet test. It looks like I am beating ZeroMQ by far so I
may be missing something here. From this benchmark it looks like ZeroMQ has
a 49 micros avg time (99% percentile) on a standard kernel =>

2 - Is there anything I can do to improve the selector reaction time when I
spin a single or very few messages? 150 micros does not look good. Or
should I assume that on a prod environment the selector will never be quite?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120823/0702b1ed/attachment.htm>

More information about the zeromq-dev mailing list