blocks|key|1148612|text|对于数量非常少的套接字(当然，根据硬件的不同而有所不同，但我们谈论的是10个或更少的套接字)，select在内存使用和运行时速度上优于epoll。当然，对于数量如此之少的套接字，这两种机制都是如此之快，以至于在绝大多数情况下，您并不真正关心这种差异。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1148613|不过，有一点需要澄清。select和epoll都是线性缩放的。然而，一个很大的不同之处在于，面向用户空间的API具有基于不同事物的复杂性。select调用的开销与您传递的编号最高的文件描述符的值大致相同。如果你选择一个fd，100，那么它的开销大约是选择一个fd，50的两倍。在最高值以下添加更多的fds并不是完全免费的，因此在实践中要比这复杂一点，但对于大多数实现来说，这是一个很好的第一近似值。|offset|length|style|CODE|1148614|epoll的开销更接近于实际包含事件的文件描述符的数量。如果您正在监视200个文件描述符，但其中只有100个文件描述符上有事件，那么您(非常粗略地)仅为这100个活动文件描述符付费。这就是epoll倾向于提供其相对于select的主要优势之一的地方。如果你有一千个大部分空闲的客户端，那么当你使用select时，你仍然要为全部一千个客户端付费。然而，使用epoll，就像你只有几个-你只为在任何给定时间处于活动状态的那些支付费用。|1148615|所有这些都意味着epoll将减少大多数工作负载的CPU使用率。至于内存使用率，这是一个有点抛出的问题。select确实设法以高度紧凑的方式表示所有必要的信息(每个文件描述符一位)。对于select可以使用的文件描述符的数量，FD_SETSIZE+(通常为1024)的限制意味着，对于select可以使用的三个fd集(读、写、异常)中的每一个，您花费的时间永远不会超过128字节。与那些最多384字节相比，epoll是一头猪。每个文件描述符都由一个多字节结构表示。但是，就绝对值而言，它仍然不会使用太多内存。您可以在几十of中表示大量的文件描述符(我认为每1000个文件描述符大约有20k+)。如果你只想监控一个文件描述符，但是它的值恰好是1024，你也可以使用select，而使用epoll，你只需要花费20个字节，这也是一个事实。尽管如此，所有这些数字都很小，所以没有太大区别。|1148616|可能您已经知道，epoll还有另一个好处，那就是它不限于FD_SETSIZE文件描述符。您可以使用它来监视尽可能多的文件描述符。如果您只有一个文件描述符，但是它的值大于FD_SETSIZE，那么epoll也可以使用它，但是select不能。|1148617|随机地，我最近还发现，与select或poll相比，epoll有一个小小的缺点。虽然这三个API都不支持普通文件(即文件系统上的文件)，但select和poll将这种缺乏支持的情况报告为始终可读和始终可写的描述符。这使得它们不适合任何有意义的非阻塞文件系统I/O，使用select或poll并且碰巧遇到来自文件系统的文件描述符的程序将至少继续操作(或者，如果失败，不是因为select或poll)，尽管可能不具有最佳性能。|1148618|另一方面，当被要求监视这样的文件描述符时，epoll将很快失败并出现错误(显然是EPERM)。严格地说，这几乎是不正确的。它只是以一种明确的方式发出了缺乏支持的信号。通常，我会为明确的失败条件鼓掌，但这种情况是没有文档记录的(据我所知)，并导致应用程序完全崩溃，而不是仅仅运行性能可能下降的应用程序。|1148619|在实践中，我只在与stdio交互时看到过这种情况。用户可以将stdin或stdout从普通文件重定向到普通文件。以前的stdin和stdout是一个管道--由epoll很好地支持--然后它变成了一个普通的文件，epoll大声地失败，破坏了应用程序。|1148620|entityMap^0|0|1X|6|0|0|1F|6|2K|6|3X|6|96|6|0|33|6|0|C|6|J|4|Q|5|1X|6|24|4|3Q|6|3X|4|56|6|5D|4|0|L|5|14|5|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@$D|X|E|Y|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@$D|11|E|12|F|G]|$D|13|E|14|F|G]|$D|15|E|16|F|G]|$D|17|E|18|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|19|8|@$D|1A|E|1B|F|G]]|9|@]|A|$]]|$1|N|3|O|5|6|7|1C|8|@$D|1D|E|1E|F|G]|$D|1F|E|1G|F|G]|$D|1H|E|1I|F|G]|$D|1J|E|1K|F|G]|$D|1L|E|1M|F|G]|$D|1N|E|1O|F|G]|$D|1P|E|1Q|F|G]|$D|1R|E|1S|F|G]|$D|1T|E|1U|F|G]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1V|8|@$D|1W|E|1X|F|G]|$D|1Y|E|1Z|F|G]]|9|@]|A|$]]|$1|R|3|S|5|6|7|20|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|21|8|@]|9|@]|A|$]]]|U|$]]

For very small numbers of sockets (varies depending on your hardware, of course, but we're talking about something on the order of 10 or fewer), select can beat epoll in memory usage and runtime speed. Of course, for such small numbers of sockets, both mechanisms are so fast that you don't really care about this difference in the vast majority of cases.

One clarification, though. Both select and epoll scale linearly. A big difference, though, is that the userspace-facing APIs have complexities that are based on different things. The cost of a <code>select</code> call goes roughly with the value of the highest numbered file descriptor you pass it. If you select on a single fd, 100, then that's roughly twice as expensive as selecting on a single fd, 50. Adding more fds below the highest isn't quite free, so it's a little more complicated than this in practice, but this is a good first approximation for most implementations.

The cost of epoll is closer to the number of file descriptors that actually have events on them. If you're monitoring 200 file descriptors, but only 100 of them have events on them, then you're (very roughly) only paying for those 100 active file descriptors. This is where epoll tends to offer one of its major advantages over select. If you have a thousand clients that are mostly idle, then when you use select you're still paying for all one thousand of them. However, with epoll, it's like you've only got a few - you're only paying for the ones that are active at any given time.

All this means that epoll will lead to less CPU usage for most workloads. As far as memory usage goes, it's a bit of a toss up. <code>select</code> does manage to represent all the necessary information in a highly compact way (one bit per file descriptor). And the FD_SETSIZE (typically 1024) limitation on how many file descriptors you can use with <code>select</code> means that you'll never spend more than 128 bytes for each of the three fd sets you can use with <code>select</code> (read, write, exception). Compared to those 384 bytes max, epoll is sort of a pig. Each file descriptor is represented by a multi-byte structure. However, in absolute terms, it's still not going to use much memory. You can represent a huge number of file descriptors in a few dozen kilobytes (roughly 20k per 1000 file descriptors, I think). And you can also throw in the fact that you have to spend all 384 of those bytes with <code>select</code> if you only want to monitor one file descriptor but its value happens to be 1024, wheras with epoll you'd only spend 20 bytes. Still, all these numbers are pretty small, so it doesn't make much difference.

And there's also that other benefit of epoll, which perhaps you're already aware of, that it is not limited to FD_SETSIZE file descriptors. You can use it to monitor as many file descriptors as you have. And if you only have one file descriptor, but its value is greater than FD_SETSIZE, epoll works with that too, but <code>select</code> does not.

Randomly, I've also recently discovered one slight drawback to <code>epoll</code> as compared to <code>select</code> or <code>poll</code>. While none of these three APIs supports normal files (ie, files on a file system), <code>select</code> and <code>poll</code> present this lack of support as reporting such descriptors as always readable and always writeable. This makes them unsuitable for any meaningful kind of non-blocking filesystem I/O, a program which uses <code>select</code> or <code>poll</code> and happens to encounter a file descriptor from the filesystem will at least continue to operate (or if it fails, it won't be because of <code>select</code> or <code>poll</code>), albeit it perhaps not with the best performance.

On the other hand, <code>epoll</code> will fail fast with an error (<code>EPERM</code>, apparently) when asked to monitor such a file descriptor. Strictly speaking, this is hardly incorrect. It's merely signalling its lack of support in an explicit way. Normally I would applaud explicit failure conditions, but this one is undocumented (as far as I can tell) and results in a completely broken application, rather than one which merely operates with potentially degraded performance.

In practice, the only place I've seen this come up is when interacting with stdio. A user might redirect stdin or stdout from/to a normal file. Whereas previously stdin and stdout would have been a pipe -- supported by epoll just fine -- it then becomes a normal file and epoll fails loudly, breaking the application.

blocks|key|1148684|text|在我公司的测试中，出现了epoll()的一个问题，因此与select相比，开销很小。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1148685|当尝试在超时的情况下从网络读取时，创建epoll_fd+(而不是FD_SET+)，并将fd添加到epoll_fd中，比创建FD_SET+(这是一个简单的malloc)的开销要大得多。|1148686|根据前面的答案，随着进程中fd的数量变大，select()的成本也变得更高，但在我们的测试中，即使fd值在10,000左右，select仍然是赢家。在这些情况下，一个线程只有一个fd在等待，并且在使用阻塞线程模型时，只是试图克服网络读取和网络写入不会超时的事实。当然，与非阻塞反应器系统相比，阻塞线程模型的性能较低，但在某些情况下，为了与特定的遗留代码库集成，需要使用阻塞线程模型。|1148687|这种用例在高性能应用程序中很少见，因为反应器模型不需要每次都创建新的epoll_fd。对于epoll_fd是长期存在的模型-这显然是任何高性能服务器设计的首选-+epoll在任何方面都是明显的赢家。|1148688|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

In tests at my company, one issue with epoll() came up, thus a single cost compared to select.

When attempting to read from the network with a timeout, creating an epoll_fd ( instead of a FD_SET ), and adding the fd to the epoll_fd, is much more expensive than creating a FD_SET (which is a simple malloc).

As per the previous answer, as the number of FDs in the process becomes large, the cost of select() becomes higher, but in our testing, even with fd values in the 10,000's, select was still a winner. These are cases where there is only one fd that a thread is waiting on, and simply trying to overcome the fact that network read, and network write, doesn't timeout when using a blocking thread model. Of course, blocking thread models are low performance compared to non-blocking reactor systems, but there are occasions where, to integrate with a particular legacy code base, it is required.

This kind of use case is rare in high performance applications, because a reactor model doesn't need to create a new epoll_fd every time. For the model where an epoll_fd is long-lived --- which is clearly preferred for any high performance server design --- epoll is the clear winner in every way.

Everything I've read and experienced ( Tornado based apps ) leads me to believe that ePoll is a natural replacement for Select and Poll based networking, especially with Twisted. Which makes me paranoid, its pretty rare for a better technique or methodology not to come with a price.

Reading a couple dozen comparisons between epoll and alternatives shows that epoll is clearly the champion for speed and scalability, specifically that it scales in a linear fashion which is fantastic. That said, what about processor and memory utilization, is epoll still the champ?

Caveats of select/poll vs. epoll reactors in Twisted

文件系统

服务器

我所阅读和体验的一切(基于龙卷风的应用程序)让我相信ePoll是精选和基于投票的网络的天然替代品，特别是在Twisted上。这让我变得偏执，很少有更好的技术或方法不付出代价的。阅读epoll和alternatives之间的几十个比较显示，epoll显然在速度和可扩展性方面处于领先地位，特别是它以一种奇妙的线性方式进行扩...

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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