linux – 如何最有效地处理大量文件描述符?
对于处理大量套接字连接的程序(例如Web服务,p2p系统等),似乎有几种选择.
>生成一个单独的线程来处理每个套接字的I / O. 在多核CPU上,我希望#5或#6具有最佳性能,但我没有任何硬数据支持这一点.搜索网页出现在this页面,描述了上述作者测试方法#2,#3和#4的经验.不幸的是,这个网页似乎是7岁左右,没有明显的最新更新. 所以我的问题是,哪些方法让人们发现效率最高和/或是否有其他方法比上面列出的方法更好?将赞赏对现实生活图,白皮书和/或网络可用书面的参考. 解决方法
说到我运行大型IRC服务器的经验,我们曾经使用select()和poll()(因为epoll()/ kqueue()不可用).在大约700个并发客户端,服务器将使用100%的CPU(irc服务器不是多线程的).然而,有趣的是服务器仍然表现良好.在大约4,000个客户端,服务器将开始滞后.
原因是大约有700个客户,当我们回到select()时,会有一个客户端可供处理. for()循环扫描以找出它将占用大部分CPU的客户端.随着我们获得更多客户,我们开始越来越多的客户需要在每次调用select()时进行处理,因此我们会变得更有效率. 转移到epoll()/ kqueue(),类似规格的机器可以轻松处理10,其中一些(可靠的更强大的机器,但仍然被认为是当今标准的机器),已经拥有30,000个客户端而没有打破汗. 我在SIGIO看到的实验似乎表明,它适用于延迟非常重要的应用程序,其中只有少数活动客户端执行非常少的个人工作. 在几乎任何情况下,我建议在select()/ poll()上使用epoll()/ kqueue().我没有尝试在线程之间拆分客户端.说实话,我从来没有找到过一项服务,需要在前端客户端处理上完成更多的操作,以证明线程的实验是合理的. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |