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

windoze

xxxxxxxp 发表于 2013-01-21 18:21
两个场景的上下文切换次数一致，性能当没有大的差别

一个sleep 8ms，另一个sleep 40ms，你如何确定“上下文切换次数一致”呢？

liuspring6

赞同linux_c_py_php的看法，业务逻辑层的处理能力对整个结构的影响往往远高于网络层的吞吐量，选什么模型取决于业务逻辑需求。有时候网络层做的再牛B，碰到业务逻辑需要大量磁盘IO、数据库访问啥的，一样卡得你蛋疼～～～

windoze

liuspring6 发表于 2013-01-21 22:17
赞同linux_c_py_php的看法，业务逻辑层的处理能力对整个结构的影响往往远高于网络层的吞吐量，选什么模型取 ...

这个“往往”往往不成立啊…………
即便它成立，IO和并发模型也是很重要的东西，模型错误拖慢应用的例子处处可见啊，例如著名的J2EE…………

liuspring6

回复 83# windoze

也许开发方向不同吧，个人接触的方向大多有大量的数据库操作，以及用户与用户，用户与NPC之间的大规模交互，这部分逻辑消耗一般都远大于传输层。
之前做过win32下线程池（用IOCP来管理）方式运行底层IO（包含文件和socket），但几年的实践证明，最忙碌的还是逻辑主线程（主逻辑十分复杂，基本不可能使用多线程并行模型），目前个人倾向于一个IO线程（IOCP/EPOLL/KQUEUE，利用超时分时间片） + 一个主逻辑线程 + N个可并行的业务逻辑线程

   

xxxxxxxp

回复 80# linux_c_py_php

我们的架构中分前后端服务器，你说的和客户交互时延不同的问题由前端服务器上的nginx等异步模型服务器来处理，他们不惧长连接（当然，攻击问题得从其他层面来考虑）。
关注问题的焦点在后端服务器（目前都是HSHA的连接模型），后端服务器由于业务逻辑复杂，通常成百上千台，且qps较低，想提升qps自然想到异步化，但异步化的代价就是对代码结构的破坏。这就涉及到一个权衡的问题，如果可以通过异步化少部分枢纽模块来获得极大的收益，这件事情就有做的意义，否则就是得不偿失。这也是我现在的一个疑问。

xxxxxxxp

回复 77# linux_c_py_php

赞同你的理解，你的描述和@windoze的描述有出入，所以想确定一下，这些模型都见过，但今天对号入座了，讨论讨论，受益匪浅。没有理解的事情是，proactor的优势在哪？似乎“reactor+非阻塞io”并没有劣势。
   

liuiang

不是搞这个方向的，不过昨晚认真的翻阅了所有的回帖，貌似学到了很多东西。mark一下，以备后用。

xxxxxxxp

回复 81# windoze


    本以为是这样的，原以为在这两个场景中造成cs的大头在时间片和sleep，后来想想，不确切

ville_lee

个人觉得你的问题本身给出了答案。
同步和异步的优劣主要取决于应用场景而不是技术本身的问题。
完全的异步IO是你调用异步IO函数，然后立即返回接着执行你的其他代码逻辑，然后当你请求的数据准备好了，通过回调或者信号通知发起IO的进程。
所以说，如果数据准备的时间为t1，操作系统调度进程或者线程直到它能够处理IO的时间为t2，那么，t1 > t2，异步的方式在执行效率上会占优势，但是如果
t1 < t2，那么同步方式会占优势。
另外，采用异步IO方式的程序设计和代码实现会比较困难，设计实现上对程序员要求更高，因为至少要求你的回调代码是可重入的，并且对于服务器类型的程序而言，
就算是在好的设计，一个进程(单线程)的处理肯定是不够的，因为数据量和吞吐率会非常高，所以还要采用多个线程，那么接着的问题就会是回调和信号都是以进程为单位发送的，
如何处理程序自身逻辑区分哪个线程请求了哪个数据，这可能就是一套大框架了。
我能想到的最后一点是CPU利用率的问题，完全是单个进程的程序对于超线程和多核的CPU的利用率不是很高。
同步多线程的程序几乎没有上述的问题，但是过多的线程也是一种系统资源消耗，所以也会有而外的消耗。

所以个人觉得，采用哪种框架，一要找出评估的标准，二要了解自己的需求和实际环境，三可能就真是实验评估了。

windoze

本来Reactor+非阻塞io就没什么问题，如果一定要说有问题也就是额外的排队层会有一些同步开销。
说到程序结构，我觉得无论用什么模型，网络服务程序从本质上说就是一个状态机，如果一开始就用这种结构写出来，改用任何模型都不是太麻烦的事。
最怕的就是一上来没搞清楚状态转移关系，写出一大坨充满if/else/switch的程序。这种代码除了用每连接一个线程的模型再没法写成别的样子了