如何解决使用单个文件描述符，select，poll和epoll与…之间是否有性能差异？
| 标题确实说明了一切。 和...还包括pselect和ppoll。 我正在处理的服务器项目基本上是由多个线程构成的。每 线程处理一个或多个会话。所有线程都是相同的。协议 负责哪个线程将主持会话。 我正在使用内部套接字类包装所有东西。兴趣点是一个checkread调用，它调用poll（linux）或select（windows）。 总之，每个线程当前在单个套接字上调用poll。据我所知，使用epoll仅在该线程正在查看多个套接字（例如HTTP服务器）时才有好处。这不是我在做的事情。该类一次只能处理一个套接字。 在epoll的手册页中对边缘和水平触发进行了简短的讨论。我不太确定这是什么意思。在套接字类中，我在代码的Windows部分中看到了一个优化，该优化使用ioctlsocket和FIONREAD来简化select调用，以检查是否有任何数据。想知道即使调用时还没有到达完整的UDP数据包，它是否也会返回> 0。这是epoll中的边缘触发吗？ 在一些基本测试中，我还发现使用select和poll没有明显的区别。 我看到使用ppoll可能会有好处，尽管由于超时精度更高。有什么想法吗？ 是的，我正在尝试为正在接收大量数据的会话优化吞吐量。服务器的网络和磁盘绑定比CPU更多。解决方法
epoll与select或poll之间的主要区别在于，epoll在单线程中运行时可扩展性更好。我不知道这与使用select或poll的多线程服务器相比如何。
看看这个http://monkey.org/~provos/libevent/libevent-benchmark2.jpg
原因（据我所知）是，当您使用select或poll时，必须遍历所有连接的套接字，以确定哪些套接字具有要读取的数据。当您使用epoll时，它将保留一个单独的数组，其中仅包含对要读取数据的套接字的引用。这样可以节省大量的循环周期，并且连接的插座越多，差异就越明显。
如果性能成为主要问题，则需要考虑的另一件事是io完成端口（仅Windows）和kqueue（仅FreeBSD）。记住epoll仅是linux也很重要。在大多数情况下，选择或轮询会很好。
在单个文件描述符的情况下，select和poll比epoll更有效，因为它要简单得多。 （epoll有一些开销，仅在单个套接字上就没有用）
,根据链接：http://www.intelliproject.net/articles/showArticle/index/io_multiplexing。
如果仅使用一个描述符：
select
poll
epoll
poll
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。