我发现啊,skynet里面的pipe用法有问题,因为是阻塞的,一次只能处理(发送一个数据包),如果同时有1000个链接由一个epoll管理,又假如每个链接进来1个 『More』
我没看明白.
skynet 对 IO 是单线程串行分发的, 如果出现拥塞跟 pipe 无关. pipe 就是用来把 IO 处理串行化.
而 skynet 的设计目的是处理 CPU 高负载的业务, 而不是 IO 高负载的业务. - 回复 | (2711) | 云风 | 2013-12-16 03:13:02
语文不好.首先我的理解是,你用pipe的目的就像zeromq一样,用来做线程间通信,减少锁,这个我也觉得很好.而我所说的跟IO高负载没关,指的是并发能力,即每秒 『More』 - 回复 | (2713) | 囧 | 2013-12-16 11:37:24
我明白你的意思. 但实际上 cpu 和 IO 都没有浪费, 只是延迟变长了而已. 因为 epoll 循环是满负荷运转的.你最初的例子中说 "发送端会积累大量的包来 『More』 - 回复 | (2716) | 云风 | 2013-12-18 11:01:02
谢谢大大解释。我并没有"把 1 万个请求包全部一次发送完",recvctrl_fd读到发送包并不是马上发送出去,而是把包挂到各个client_fd的发送队列上,然后设置client_fd的EPOLLOUT事件,统一由epoll来管理调度。对于游戏来说,我觉得反应速度也很重要啊,我搞页游的。 - 回复 | (2717) | 3q | 2013-12-18 02:34:55
反应速度是很重要. 我的意思是这种延迟不会太长, 也没有任何地方浪费 IO 和 CPU 的处理能力(没有线程空转) 反而适当的延迟可能还会对用户体验有好处:比如一个用户高频发包,如果你高频回应它, 可能低频发包的用户反而延迟更大了(你把 cpu 和 IO 都分给了高频用户)
现在的设计其实是优先收包, 发包的优先级低一些(仅仅是优先级低,并没有故意延迟和浪费 IO 处理能力). 我认为是适用于网络游戏这种业务的。
简单说, 即使把反应时间从 2ms 提到到 1ms, 也远远小于网络传输的时间. IO 处理能力和 CPU 处理能力没有浪费就可以了.
如果想增加 epoll 循环中的 recvctrl_fd 的处理频率, 可以简单在在 blockread 后加一个 select 重复处理就可以了. 我觉得意义不是很大.