Many small UDP datagrams vs fewer, larger ones

Question

I have a system that sends "many" (hundreds) of UDP datagrams in bursts, every once in awhile (say, 10 times a minute). According to nload, this averages about 222kBit/s. The content of these datagrams is JSON. I've considered altering the system so that it waits some time (500ms?) and combines many of the JSON objects into one datagram, before sending. But I'm not sure it's worth the effort (bandwidth, protocol, frequency of sending considered.) Would the new approach provide any real benefits over the current one?

Answer 1

The short answer is that it's up to you to decide that.

The long version is that it depends on your use case. Since we don't know what you're building, it's hard to say what's more important - latency? Throughput? Reliability? Something else? Let's analyze some pros and cons. Here's what I came up with:

Pros to sending larger packets:

• Fewer messages means fewer system calls and less I/O against the network. That means fewer blocked/waiting threads and less time spent on interrupts.
• Fewer, larger packets means less overhead for each individual packet (stuff like IP/UDP headers that's send with each packet). Therefore a higher data rate is (theoretically) achievable, although keep in mind that all of these headers (L2+IP+UDP) typically add up to no more than 60-70 bytes per packet since the UDP header is only 8 bytes long.
• Since UDP doesn't guarantee ordering, larger packets with more time between them will reduce any existing reordering.

Cons to sending larger packets:

• Re-writing existing code, and making it (slightly) more complicated.
• UDP is unreliable, so a loss of a single (large) packet would be more significant compared to the loss of a small packet.
• Latency - some data will have to wait 500ms to be sent. That means that a delay is added between the sender and the receiver.
• Fragmentation - if one of the packets you create crosses the MTU boundary (typically 1450-1500 bytes including the IP+UDP header, which is normally 28 bytes long), the IP layer would need to fragment the packet into several smaller ones. IP fragmentation is considered bad for a multitude of reasons.
• Processing of larger packets might take longer