sockets - 什么是n个文件描述符，之后最好通过轮询切换到epoll？

Question

对于1到50左右的描述符范围，我们是否有基准？我看到的大多数基准测试都是针对大量描述符100s..1000s ...

我目前正在使用具有16个描述符的民意调查，并考虑使用epoll是否会提高应用程序的速度。

Please advise in 3 scenarios with 16 socket descriptors in the set for poll/epoll:
1. most of the sockets are active...>both should be same performance?
2. half active half idle....what is better here?
3. mostly idle...> clearly epoll is better ?

Answer 1

我非常怀疑从poll()切换到epoll()不会对应用程序的性能产生任何影响。当您有许多文件描述符(数百个或数千个)时，epoll()的主要优点就会显现出来，在这种情况下，标准poll()每次调用都需要做更多的工作，而epoll()会事先进行设置-只要您不进行更改您正在观看的文件描述符集，每个调用都快一点。但是通常这种差异仅对于许多文件描述符才是明显的。

请记住，如果您正在监视的文件描述符集非常频繁地更改，则epoll()的主要优势会丢失，因为您仍需要进行将新文件描述符传递到内核的工作。因此，如果您要处理许多短暂的连接，那么切换到该连接的吸引力就更小了。

另一个区别是epoll()可以是边沿触发的，其中仅在描述符上发生新 Activity 时才返回调用，或者是级别触发的，其中调用在描述符可读写时返回。标准poll()调用始终是级别触发的。但是，对于大多数人而言，他们想要的是电平触发的-边缘触发的接口(interface)有时会有用，但是在大多数情况下，它们会导致竞争状态，在读取后但进入epoll()调用之前，数据到达套接字。我的建议是远离边缘触发的代码，除非您真的非常了解自己在做什么。

您为epoll()付出的代价是缺乏可移植性-poll()和select()都是标准POSIX接口(interface)，因此使用它们将使您的代码更加可移植。另一方面，epoll()调用仅在Linux上可用。其他一些Unix变体也有它们自己的等效机制，例如FreeBSD上的kqueue，但是在这种情况下，您必须为每个平台编写不同的代码。

我的建议是直到您到达使用许多文件描述符的地步，甚至不用担心epoll()-认真地讲，几乎可以肯定的是，代码中还有很多其他地方可以实现更大的性能改进，并且epoll()完全有可能无论如何都不会比您的用例更快。

如果确实要处理许多连接，而其余代码已经非常理想，那么您应该首先考虑使用libev这样的跨平台接口(interface)，它在每个特定平台上使用最佳性能调用。它是performs very well，即使您只想支持Linux，也比直接使用epoll()总体上没有麻烦。

到目前为止，我还没有提到您提到的三种情况，因为我不相信它们中的任何一种都会对少量的文件描述符(例如16)执行不同的操作。对于大量的文件描述符，epoll()的性能应特别优于poll()。那里大多数是空闲文件描述符。如果所有文件描述符始终处于 Activity 状态，则两个调用都需要遍历每个连接以进行处理。但是，随着空闲连接比例的增加，epoll()会提供更好的性能，因为它仅返回 Activity 的连接-使用poll()，您仍然必须遍历所有内容，并且大多数都将被跳过，但是epoll()仅返回您需要处理的那些连接(您可以指定的最大限制)。

要明确地说明这一点(如上所述，这仅与大量连接有关):

大多数套接字都处于 Activity 状态:这两个调用大致相当，也许epoll()仍在前面。

半 Activity 半闲:希望epoll()在这里会更好一些。

大多数情况下是空闲的:希望epoll()在这里肯定会更好。

编辑:

您可能想看看 this graph，它来自libevent作者，显示了随着文件描述符数量的变化而处理事件的相对开销。注意所有的线如何在原点周围收敛，表明所有机制对于少量的描述符都具有可比的性能。