[换个地方发]请教大牛：异步io的优点究竟在哪

xxxxxxxp

回复 70# starwing83

可能没说清楚，场景A指处理线程收到请求后sleep 5ms后回复请求，场景B指处理线程收到请求后sleep 40ms后回复请求。连接数？客户端向服务端按一定速度发短连接请求，连接数可以推出来
   

starwing83

回复 51# xxxxxxxp


    不太明白第二个同步样例里面的cs和中断数啥意思。中断数是指的被系统调度的次数么？

第一个样例里面倒是可以解释：这证明工作线程的工作量对吞吐量产生了显著的影响呗……而且工作线程工作量增加8倍，处理速度只降低了一倍，已经可以了呗= =

其实你如果有兴趣，根据这个就可以把上下文切换的代价计算出来了。其实并不大。

xxxxxxxp

回复 72# starwing83

没有多出工作量啊，处理线程直接sleep，又不是分别执行5ms或40ms的计算
   

folklore

看成
换个地方吹大牛
了

starwing83

回复 73# xxxxxxxp


    sleep以后被打断会重新睡。根本不会提前醒的。

本质上就是干了40ms的活儿，而且CPU占用率还非常低——时间都浪费给时间片轮转了，大家都没干活。

xxxxxxxp

回复 52# windoze

按你这个分类，lightty的那种处理方式属于proactor喽？

linux_c_py_php

个人理解在操作系统自身不提供异步I/O接口的情况下, reactor和proactor相当于网络框架是否为用户完成了网络I/O操作, 即参考libevent的event和bufferevent, 前者只告知用户发生了读事件并传给用户的回调, 后者则不仅监听了读事件并将内容读回来之后回调交给用户处理.

不知道自己理解是否有误.

linux_c_py_php

lighttpd? 非网络框架, 不需要考虑区分reactor / proactor,  从根上讲是reactor, 实际上应该就是个epoll, 对于linux来说, 这俩模式是没有质的区别的.

xxxxxxxp 发表于 2013-01-21 20:27
回复 52# windoze

按你这个分类，lightty的那种处理方式属于proactor喽？

xxxxxxxp

回复 75# starwing83

没太懂，我现在的想法是处理时间短的场景吞吐量大，一小部分线程就可以胜任工作，以致cs较小
   

linux_c_py_php

做服务得综合考虑以下, 给你个例子:

面对局域网和面对广域网的服务, 选网络模型就要考虑的不一样了, 因为网络环境不同, 面对的用户不同.

撇开攻击不说, 最朴素的多线程模型1:1的服务模式, 各客户端网络延迟不同, 你的吞吐率就会直接受到用户影响, 如果是采用epoll的1:n服务模式, 这种问题没多大困扰.

但如果业务逻辑复杂耗时, 那么多线程服务模式最简单实现, 但单线程epoll+业务线程池会兼有两种优点, 是更好的选择.


不要研究什么模式了, 多写几个项目, 多吃点亏就见完所有模式了!

xxxxxxxp 发表于 2013-01-21 20:59
回复 75# starwing83

没太懂，我现在的想法是处理时间短的场景吞吐量大，一小部分线程就可以胜任工作， ...