问Twisted中select/poll与epoll反应堆的比较

EN

对于数量非常少的套接字(当然，根据硬件的不同而有所不同，但我们谈论的是10个或更少的套接字)，select在内存使用和运行时速度上优于epoll。当然，对于数量如此之少的套接字，这两种机制都是如此之快，以至于在绝大多数情况下，您并不真正关心这种差异。

不过，有一点需要澄清。select和epoll都是线性缩放的。然而，一个很大的不同之处在于，面向用户空间的API具有基于不同事物的复杂性。select调用的开销与您传递的编号最高的文件描述符的值大致相同。如果你选择一个fd，100，那么它的开销大约是选择一个fd，50的两倍。在最高值以下添加更多的fds并不是完全免费的，因此在实践中要比这复杂一点，但对于大多数实现来说，这是一个很好的第一近似值。

epoll的开销更接近于实际包含事件的文件描述符的数量。如果您正在监视200个文件描述符，但其中只有100个文件描述符上有事件，那么您(非常粗略地)仅为这100个活动文件描述符付费。这就是epoll倾向于提供其相对于select的主要优势之一的地方。如果你有一千个大部分空闲的客户端，那么当你使用select时，你仍然要为全部一千个客户端付费。然而，使用epoll，就像你只有几个-你只为在任何给定时间处于活动状态的那些支付费用。

所有这些都意味着epoll将减少大多数工作负载的CPU使用率。至于内存使用率，这是一个有点抛出的问题。select确实设法以高度紧凑的方式表示所有必要的信息(每个文件描述符一位)。对于select可以使用的文件描述符的数量，FD_SETSIZE (通常为1024)的限制意味着，对于select可以使用的三个fd集(读、写、异常)中的每一个，您花费的时间永远不会超过128字节。与那些最多384字节相比，epoll是一头猪。每个文件描述符都由一个多字节结构表示。但是，就绝对值而言，它仍然不会使用太多内存。您可以在几十of中表示大量的文件描述符(我认为每1000个文件描述符大约有20k )。如果你只想监控一个文件描述符，但是它的值恰好是1024，你也可以使用select，而使用epoll，你只需要花费20个字节，这也是一个事实。尽管如此，所有这些数字都很小，所以没有太大区别。

可能您已经知道，epoll还有另一个好处，那就是它不限于FD_SETSIZE文件描述符。您可以使用它来监视尽可能多的文件描述符。如果您只有一个文件描述符，但是它的值大于FD_SETSIZE，那么epoll也可以使用它，但是select不能。

随机地，我最近还发现，与select或poll相比，epoll有一个小小的缺点。虽然这三个API都不支持普通文件(即文件系统上的文件)，但select和poll将这种缺乏支持的情况报告为始终可读和始终可写的描述符。这使得它们不适合任何有意义的非阻塞文件系统I/O，使用select或poll并且碰巧遇到来自文件系统的文件描述符的程序将至少继续操作(或者，如果失败，不是因为select或poll)，尽管可能不具有最佳性能。

另一方面，当被要求监视这样的文件描述符时，epoll将很快失败并出现错误(显然是EPERM)。严格地说，这几乎是不正确的。它只是以一种明确的方式发出了缺乏支持的信号。通常，我会为明确的失败条件鼓掌，但这种情况是没有文档记录的(据我所知)，并导致应用程序完全崩溃，而不是仅仅运行性能可能下降的应用程序。

在实践中，我只在与stdio交互时看到过这种情况。用户可以将stdin或stdout从普通文件重定向到普通文件。以前的stdin和stdout是一个管道--由epoll很好地支持--然后它变成了一个普通的文件，epoll大声地失败，破坏了应用程序。

在我公司的测试中，出现了epoll()的一个问题，因此与select相比，开销很小。

当尝试在超时的情况下从网络读取时，创建epoll_fd (而不是FD_SET )，并将fd添加到epoll_fd中，比创建FD_SET (这是一个简单的malloc)的开销要大得多。

根据前面的答案，随着进程中fd的数量变大，select()的成本也变得更高，但在我们的测试中，即使fd值在10,000左右，select仍然是赢家。在这些情况下，一个线程只有一个fd在等待，并且在使用阻塞线程模型时，只是试图克服网络读取和网络写入不会超时的事实。当然，与非阻塞反应器系统相比，阻塞线程模型的性能较低，但在某些情况下，为了与特定的遗留代码库集成，需要使用阻塞线程模型。

这种用例在高性能应用程序中很少见，因为反应器模型不需要每次都创建新的epoll_fd。对于epoll_fd是长期存在的模型-这显然是任何高性能服务器设计的首选- epoll在任何方面都是明显的赢家。