Twisted选择/轮询与epoll反应器的注意事项

Question

我所阅读和经历的一切（基于Tornado的应用程序）都让我相信，ePoll是基于Select和Poll的网络的自然替代品，特别是Twisted。这让我产生了偏执狂，这对于一种更好的技术或方法来说并不合适，因为它并不具备价格。

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

Answer 1

对于非常少量的套接字（当然，这取决于您的硬件，但我们正在谈论的东西大约在10或更少），选择可以在内存使用率和运行时速度上击败epoll。当然，对于这样少量的套接字，这两种机制都非常快，所以在绝大多数情况下，您并不关心这种差异。

虽然有一个解释。选择和epoll线性缩放。然而，一个很大的区别是面向用户空间的API具有基于不同事物的复杂性。调用select的成本大致与通过它的最高编号的文件描述符的值相同。如果你选择一个单一的fd，100，那么这个花费大约是选择一个单一的fd50的两倍。在最高点以下添加更多的fds不是很自由，所以在实践中它比这更复杂一点，但是这个对大多数实现来说是一个很好的第一个近似值

epoll的成本更接近实际上有事件的文件描述符的数量。如果您正在监视200个文件描述符，但其中只有100个文件描述符有事件发生，那么您（非常粗略地）仅支付这100个活动文件描述符。这是epoll倾向于提供超过选择的主要优点之一。如果你有一千个大多数闲置的客户，那么当你使用select的时候，你仍然在为所有的客户付费。然而，对于epoll来说，就像你只有几个 - 你只支付那些在任何特定时间都处于活动状态的人。

所有这一切意味着epoll将导致大多数工作负载的CPU使用率降低。就内存使用情况而言，这是一个折腾。 select确实设法以高度紧凑的方式表示所有必要的信息（每个文件描述符一位）。 FD_SETSIZE（通常为1024）限制您可以与select一起使用多少个文​​件描述符，这意味着您将永远不会为可用于select（读取，写入，例外）的三个fd集中的每一个花费超过128个字节。相比于那些384字节的最大值，epoll就像是一头猪。每个文件描述符都由多字节结构表示。但绝对而言，它仍不会占用太多内存。你可以用几十千字节表示大量的文件描述符（我认为大概每1000个文件描述符有20k）。如果你只想监视一个文件描述符，但是它的值恰好是1024，那么你必须花费所有这些字节的384个字节与select这一事实，而你只花费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将会是一个由epoll支持的管道 - 然后它变成了一个普通的文件，epoll会大声地失败，从而破坏应用程序。

Answer 2

在我公司的测试中，epoll（）的一个问题出现了，因此与select相比单个成本。

当尝试从超时网络读取数据时，创建epoll_fd（而不是FD_SET）并将fd添加到epoll_fd，比创建FD_SET（这是一个简单的malloc）要昂贵得多。

根据之前的答案，随着过程中FD的数量变大，select（）的成本变高，但在我们的测试中，即使在10,000的fd值中，select依然是赢家。这些情况下只有一个线程正在等待的fd，并且只是试图克服网络读取和网络写入在使用阻塞线程模型时不超时这一事实。当然，与非阻塞反应堆系统相比，阻塞螺纹模型的性能较差，但有些情况下需要与特定的遗留代码库集成。

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