Comment by buybackoff
Comment by buybackoff a day ago
One of the greatest things about Aeron is just the fact it exists. If one goes e.g. to StackOverflow or a place with the same patronizing attitude of "experts", they will tell you no one needs UDP, even in the same DC on reliable network, especially no one needs multicast. Any sane person should use TCP with a loop for multiple destinations, they would say, and one should measure before optimizing, they would say. But they themselves probably never had a chance to measure. Yet Aeron guys, who are real expert in low-latency systems, just delivered an ultra-fast thing that is quite simple in design.
Aeron latency histograms vs TCP are quite nice in the same DC on enterprise-grade networking hardware. But it really makes sense to use if a single-digit or low-double digit microsecond latency improvement on P50 is worth the effort. Or if the long tail with TCP is a dealbreaker, as Aeron has much nicer P99+ regardless of how well optimized a TCP setup is. Also, if one can leverage multicast that's nice, but not only clouds have it disabled, and Aeron works fine with unicast to N.
However, there are gotchas with threading and configuration overall. Cross-DC setup may surprise in a bad way if buffers are not configured to account for bandwidth-delay product. Any packet loss on high-latency network leads to a nasty NACK storm that is slow to recover under load. It's better to set the highest QoS and ensure the network is never dropping packets, e.g. calculate the real peak instant load vs hardware capacity. Relative latency savings cross-DC become less interesting the longer the distance, so there's nothing wrong with TCP there. Another note is that, e.g. ZMQ is slow not because of TCP but because of its internals, almost 2x slower for small packets than raw well-tuned TCP sockets, which are not that bad vs Aeron. Also, Aeron is not for sending big blobs around, the best is to use it with small payloads.
Aeron is designed with mechanical sympathy in mind by the guys who coined this term and have been evangelizing it for years, and it's visible. Lots to learn from the design & implementation (tons of resources on the web) even without using it in prod.
One time I was setting up a jboss cluster on vmware boxes - two right next to each other in the rack. JBoss used (uses?) multicast discovery to find the cluster and the VMs on different boxes just couldn't find each other.
Another time I had a backup job using uftp (a multicast file xfer tool) and it was a similar story. Systems literally sitting one rack over couldn't talk.
We involved all of our CC*-certified guys, wasted a week, and eventually just used the explicit command line switches to configure the cluster.
The hardware is not up to the task, physical or virtual, as far as I can tell.