Mat*_*att 14 c++ sockets select epoll
标题真的说明了一切.
和...意味着还包括pselect和ppoll ..
我正在处理的服务器项目基本上是用多个线程构建的.每个线程处理一个或多个会话.所有线程都是相同的.该协议负责管理哪个线程会话.
我正在使用一个内部套接字类来包装东西.感兴趣的点是一个检查调用,它调用poll(linux)或select(windows).
总之,每个线程当前在单个套接字上调用poll.据我所知,如果这个线程正在查看多个套接字,例如你在HTTP服务器中得到的东西,那么使用epoll只会有好处.那不是我在做的事情.并且该类一次只处理一个套接字.
在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：201微秒。poll：159微秒。epoll：176微秒。poll在这种情况下，似乎将是更好的解决方案。