从性能上看，投票与recv、epoll与recv和简单recv之间的差异？

Question

从性能上看，投票与recv、epoll与recv和简单的recv有什么不同？我有四个多播流，我必须要听，我想我有三个选择。我想从速度、系统调用、上下文切换的角度看哪个更好。

1 poll with recv
2 epoll with recv
3 4 threads with recv

请告诉我哪一个更好，为什么？

Answer 1

在你选择的三种解决方案中，哪一种不会有多大关系，差异也不会很大。然而，有一个将允许您保存syscalls (见末尾)。

对于4个描述符，您可以假设poll与epoll几乎一样快。对于400或4,000个描述符来说，这是非常不同的，但是对于4个描述符，poll是绝对可以接受的(当然，您仍然可以使用epoll，只是不要期待奇迹)。epoll的重要之处在于它如何扩展它所监视的描述符的数量，而不是监视其中的极少数描述符的速度。

轮询(带有两个函数)和接收显然比在线程中直接接收还要多一个syscall，尽管取决于问题的确切性质，这可能是一种过于天真的看待问题的方法。

如果来自这4个多播地址的数据报可以独立处理，您只需在recv (最简单的解决方案！)上的每个端口和块上触发一个进程，但否则您需要某种同步，如果您以前没有这样做，就很难得到正确的同步，并且可能()涉及额外的系统或旋转，并且很可能比多路复用接收慢。

上下文开关的数量将大致跟随syscalls的数量，无论您是否有线程(因为您在syscalls中的大部分时间都是阻塞的)，除非您有一个非常繁忙的机器，很少有空闲的核心。在这种情况下，向游戏中抛出线程将显著增加上下文切换的数量。

多播假定为UDP，意思是“完整的数据报”。由于您考虑使用epoll，所以您已经确定可移植性不是一个问题。因此，您也可以使用另一个特定于Linux的syscall：recvmmsg。这允许您只使用一个syscall接收多个数据报。如果您只有一个套接字，您只需阻止它，因为它提供了一个“接收最多n”的功能。但是，由于您仍然需要复用4个套接字，所以您将首先使用epoll，然后使用recvmmsg。