对 UDP 服务器进行基准测试
我正在将一个 UDP 侦听器从 Java 重构为 C。它每秒需要处理 1000 到 10000 条 UDP 消息,平均数据长度约为 60 字节。无需回复。数据不能丢失(不要问为什么决定使用UDP)。
我分叉了一个进程来处理传入的数据,以便我可以尽快接收数据,而不会填满我的内核缓冲区。然后孩子处理收到的数据。
简而言之,我的算法是:
监听数据。
收到数据后,检查是否有错误。
叉掉一个孩子。
如果我是个孩子,请按照我的方式处理数据并退出。
如果我是父母,收获任何僵尸孩子 waitpid(-1, NULL, WNOHANG)
。
重复。
首先,您对上述内容有何评论?我正在使用 socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)
创建套接字,并与 AF_INET
和 INADDR_ANY
以及 recvfrom
进行绑定> 没有标志。
其次,任何人都可以建议我可以用来测试该应用程序(或至少侦听器)是否可以处理比我预期更多的消息?或者,我是否需要将一些东西组合在一起才能做到这一点。
我猜后者会更好,这样我就可以比较生成的数据与接收的数据。但是,如有意见,我们将不胜感激。
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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您将丢失数据,除非您自己在 udp 之上实现了可靠的传送。
在我看来,就像你每包一个孩子就换掉一个孩子?如果是这样,那将是相当低效的 - 如果您需要每秒处理 1000-10000 条消息,那么您将创建 1000-10000 个进程/秒。而是在周围保留一个工作人员池,并通过某种形式的 IPC 与他们进行通信。
至于测试这一点,我建议您组合一个与服务器上的日志记录/跟踪一起工作的客户端。您将完全控制发送速率,您可以发送您喜欢的任何消息(例如,包含您自己的序列号以验证发送)。
You will lose data, unless you've implemented reliable deliviry yourself on top of udp.
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).