networking - Twisted 中 select/poll 与 epoll react 器的注意事项

Question

我读过和经历的一切(基于 Tornado 的应用程序)让我相信 ePoll 是基于 Select 和 Poll 的网络的自然替代品，尤其是 Twisted。这让我很偏执，对于更好的技术或方法论来说，这是非常罕见的。

阅读 epoll 和替代品之间的几十个比较表明，epoll 显然是速度和可扩展性的冠军，特别是它以线性方式扩展，这非常棒。也就是说，处理器和内存利用率如何，epoll 仍然是冠军吗？

Answer 1

对于非常少的套接字(当然取决于你的硬件，但我们谈论的是 10 个或更少的数量级)，select 可以在内存使用和运行速度方面击败 epoll。当然，对于如此少量的套接字，两种机制都非常快，以至于在绝大多数情况下您并不真正关心这种差异。

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

epoll 的成本更接近实际包含事件的文件描述符的数量。如果您正在监视 200 个文件描述符，但其中只有 100 个具有事件，那么您(非常粗略地)只需为这 100 个事件文件描述符付费。这是 epoll 倾向于提供其优于 select 的主要优势之一的地方。如果您有 1000 个大部分闲置的客户端，那么当您使用 select 时，您仍然需要为所有 1000 个客户付费。但是，使用 epoll，就好像您只有几个 - 您只需为在任何给定时间处于事件状态的那些付费。

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

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

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

另一方面，epoll当被要求监视这样的文件描述符时，将快速失败并出现错误(显然是 EPERM )。严格来说，这几乎是不正确的。它只是以明确的方式表明它缺乏支持。通常我会为明确的故障条件鼓掌，但这个没有记录(据我所知)并导致应用程序完全损坏，而不是仅以潜在的性能下降的方式运行的应用程序。

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