[基于Epoll内置Leader-Follower服务端实现, 已可达50万echo qps（全新支持Lua啦）]

yulihua49

iw1210 发表于 2013-02-26 16:59
对已经连接的fd，收数据由select的那个线程做，发数据由其他线程做啊

select那个线程只处理事件，别的什么都不做！！！
收发都是ｗｏｒｋ干的，要么怎么能１６Ｗ的ＱＰＳ。

yulihua49

iw1210 发表于 2013-02-26 17:00
没有新的fd，为啥要FD_CLR？

＝ONESHOT
程序都给你了看看再说行不？下班，明天见。

yulihua49

iw1210 发表于 2013-02-26 17:06
你这只是个测试程序啊

测试程序已经包含了完整的流程，已经说明了所有有关的原理，一共才400多行，结构也是很清晰的（参照151楼），你就没有读这个的能力如何担当大任？
问题已经回答了，=EPOLLONESHOT，=  ones hot,只热一次，防止还未处理又被激活（见15楼）。
你把这个帖子从头到尾仔细看看行不，很多答案就在里边，我已经重复回答你很多次了。一些知识点是需要你自己通过逻辑思维扩展成知识面的。你看东西也很不仔细，帖子里
说过的，程序里有的，你还重复的问。

yulihua49

zozoiiiiii 发表于 2013-02-26 20:33
能科普下不，qps怎么算，比如当前主流1000M网卡：
1000Mbit/s = 128MB/s, 如果每条消息包含100bytes，则该 ...

楼主在localhost上测试。我在100M网上测试，你算的正确，极限就是这些。最小的平均包长是75字节。

yulihua49

iw1210 发表于 2013-02-27 11:33
回复 219# yulihua49

我知道你为啥要重新FD_CLR了，是不是这个原因 http://bbs.chinaunix.net/thread-4 ...

对的，再看219楼。
逻辑推理一下：
我们的qps达到16W/S，平均6微秒请求一次，每个请求都要激活事件，每次select可以激活事件少则十几个，多则500-800.
你说，select收事件注册能耽误吗？如果不能耽误，你可能在select后本线程作IO吗？IO肯定是别人做的，那完成后怎么及时通知select？

yulihua49

iw1210 发表于 2013-02-27 11:46
回复 222# yulihua49
epoll里的概念？我们用select做成了，就不考虑epoll了

不光是epoll，所有的事件处理都有这个概念，只是实现方法不同。

yulihua49

iw1210 发表于 2013-02-27 11:56
我的做法是有select的那个线程只收数据不发数据，发数据由其他线程做

那你就甭想达到16W/S啦，6微秒，连一个IO都做不完。况且，收完马上就会有一个复杂的业务逻辑，你也这个线程干？多线程白搭了？
什么叫“众人拾柴火焰高”，你让work干嘛，有好多work的嘛。
见153楼。
我那个标记就是rfds,wfds,efds。

yulihua49

iw1210 发表于 2013-02-27 12:07
其他线程处理数据流时给描述符做标记，调用select前只加有标记的描述符，实现异步处理，效率应该没问题 ...

你试试吧，也发个测试结果来？
有人说select只能3000qps，16Wqps怎么做的？你把几个方案都测测。

yulihua49

iw1210 发表于 2013-02-28 09:02
为啥要用FD_CLR？ 看我这个提问：
http://bbs.chinaunix.net/thread-4069105-1-1.html

首先，我答复的是我的程序，与你自己的程序和想法无关。
其次，你没有看我的程序就提问题，你仔细看看我的程序，我清的是select的那些fds吗？根本不是！！！我清掉的是我自己的标志！！
防止活动再次提交，实现ONESHOT。
之所以人家要提供这个功能，必然是有时要用。

爱提问题是你的优点，但是要过过脑子，这个问题你提了多遍，我也回答了多遍了。

yulihua49

linux_c_py_php 发表于 2013-02-18 00:02
程序在论坛众亲友的给力指导下, 在公司内核部门的指导之下, 长连接性能最终达到了50万qps, 短连接性能最 ...

给你测了一下往返时间。
本机往返一次100微秒左右，100M LAN 300微秒左右。