>生成一个单独的线程来处理每个套接字的I / O.
>使用select系统调用将I / O复用到单个线程中.
>使用poll系统调用复用I / O(替换选择).
>使用epoll系统调用以避免必须通过用户/系统边界重复发送套接字fd.
>生成许多I / O线程,每个线程使用poll API复用一组相对较小的连接总数.
>按照#5,除了使用epoll API为每个独立的I / O线程创建一个单独的epoll对象.
在多核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().我没有尝试在线程之间拆分客户端.说实话,我从来没有找到过一项服务,需要在前端客户端处理上完成更多的 *** 作,以证明线程的实验是合理的.
总结以上是内存溢出为你收集整理的linux – 如何最有效地处理大量文件描述符?全部内容,希望文章能够帮你解决linux – 如何最有效地处理大量文件描述符?所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)