Dav*_*vid 91 networking scalability capacity-planning twisted
我所阅读和体验过的所有东西(基于Tornado的应用程序)都让我相信ePoll是基于Select和Poll的网络的自然替代品,特别是对于Twisted.这让我变得偏执,对于更好的技术或方法而言,这是非常罕见的.
阅读epoll和替代品之间的几十个比较表明,epoll显然是速度和可扩展性的支柱,特别是它以线性方式扩展,非常棒.那说,处理器和内存利用率如何,epoll仍然是冠军？
Jea*_*one 187
对于非常少量的套接字(当然,这取决于你的硬件,但我们讨论的是大约10或更少的东西),select可以在内存使用和运行时速度上击败epoll.当然,对于如此少量的套接字,这两种机制都是如此之快,以至于在绝大多数情况下你并不真正关心这种差异.
但有一点澄清.选择和epoll线性地缩放.但是,一个很大的区别是面向用户空间的API具有基于不同事物的复杂性.select呼叫的成本大致与您传递的最高编号文件描述符的值相关.如果你选择一个单独的fd,100,那么这大约是选择单个fd的两倍,50.添加更多fds低于最高值并不是很自由,所以它在实践中比这更复杂,但是这个对于大多数实现来说是一个很好的第一近似.
epoll的成本更接近实际上有事件的文件描述符的数量.如果您正在监视200个文件描述符,但只有100个文件描述符,那么您(非常粗略地)只支付这100个活动文件描述符.这就是epoll倾向于提供其优于SELECT的主要优势之一.如果你有一千个大多数闲置的客户,那么当你使用select时,你仍然需要支付全部一千个.然而,有了epoll,就像你只有一些 - 你只需支付任何给定时间活跃的那些.
所有这些意味着epoll将导致大多数工作负载的CPU使用率降低.就内存使用而言,它有点折腾. select确实设法以高度紧凑的方式表示所有必要的信息(每个文件描述符一位).对于可以使用多少个文件描述符的FD_SETSIZE(通常为1024)限制select意味着您可以永远不会为可以使用的三个fd集中的每一个花费超过128个字节select(读,写,异常).与最大的384个字节相比,epoll有点像猪.每个文件描述符由多字节结构表示.但是,从绝对意义上说,它仍然不会占用太多内存.您可以用几十千字节表示大量的文件描述符(我认为大约每1000个文件描述符20k).select如果你只想监视一个文件描述符但它的值恰好是1024,那么你也可以抛出你必须花费所有384个字节的事实,而epoll你只需要花费20个字节.尽管如此,所有这些数字都很小,所以它并没有太大的区别.
还有epoll的其他好处,也许你已经知道,它不仅限于FD_SETSIZE文件描述符.您可以使用它来监视尽可能多的文件描述符.如果你只有一个文件描述符,但它的值大于FD_SETSIZE,epoll也可以使用,但select不是.
随机地,我最近也发现了epoll与selector 相比的一个小缺点poll.虽然没有这三个API支持普通文件(文件系统上的即文件),select而poll目前这种缺乏支持,报告这样的描述符一如既往可读和可写的始终.这使得它们不适合任何有意义的非阻塞文件系统I/O,使用select或poll碰巧遇到来自文件系统的文件描述符的程序将至少继续运行(或者如果它失败,它将不会因为的select或poll),尽管它也许不是最佳的性能.
另一方面,当被要求监视这样的文件描述符时,epoll将很快失败并显示错误(EPERM显然).严格来说,这几乎不正确.它只是以明确的方式表明它缺乏支持.通常情况下,我会为明确的失败条件鼓掌,但是这个条款没有记录(据我所知)并导致完全破坏的应用程序,而不是仅仅运行可能性能下降的应用程序.
在实践中,我见过这个唯一的地方就是在与stdio交互时.用户可能将stdin或stdout从/向正常文件重定向.以前stdin和stdout本来是一个管道 - 由epoll支持就好了 - 然后它变成了一个普通文件,epoll大声失败,破坏了应用程序.