Benchmarking a UDP server

Question

I am refactoring a UDP listener from Java to C. It needs to handle between 1000 and 10000 UDP messages per second, with an average data length of around 60 bytes. There is no reply necessary. Data cannot be lost (Don't ask why UDP was decided).

I fork off a process to deal with the incoming data so that I can recvfrom as quickly as possible - without filling up my kernel buffers. The child then handles the data received.

In short, my algo is:

Listen for data.
When data is received, check for errors.
Fork off a child.
If I'm a child, do what I with the data and exit.
If I'm a parent, reap any zombie children waitpid(-1, NULL, WNOHANG).
Repeat.

Firstly, any comments about the above? I'm creating the socket with socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP), binding with AF_INET and INADDR_ANY and recvfrom with no flags.

Secondly, can anyone suggest something that I can use to test that this application (or at least the listener) can handle more messages than what I am expecting? Or, would I need to hack something together to do this.

I'd guess the latter would be better, so that I can compare data that is generated versus data that is received. But, comments would be appreciated.

Answer 1

Data cannot be lost

You will lose data, unless you've implemented reliable deliviry yourself on top of udp.

Listen for data. When data is received, check for errors. Fork off a child.

It sounds to me like you fork off a child for every packet ? If so, that's going to be rather inefficient - you'll create 1000-10000 processes/sec if you need to handle 1000-10000 messages/sec. Rather keep a pool your workers around, and communicate to them via some form of IPC.

As for testing this, I'd suggest you throw together a client that works together with logging/tracing on the server. You'll have full control over the sending rate, you can send whatever messages you like (e.g. include your own sequence numbers for verifying the delivery).

Answer 2

You will lose data, unless you've implemented reliable deliviry yourself on top of udp.

Yeh, I'm aware of that, unfortunately it is a key design decision done before I joined the project. My intention is to lose as little as possible on the server side of things. If packets are dropped somewhere in the ether, well, that is nothing I can do.

The pool of workers sound like a great idea, I know it is implemented in other daemons. Obviously, the optimal number of workers required would be something that I can only figure out in testing.

Much appreciated, and thank you.