Proactor VS Reactor
通常，Reactor只允许收发在同一线程，底层使用select函数监听IO事件，回调handle_input，handle_output等函数，显然，这种框架存在瓶颈： 1.收发在同一线程，且采用同步方式接收和发送，对收发数据频繁且数据量较大的系统，收发肯定是系统瓶颈；2.reatcor底层采用select,对于支持多个连接的系统，select轮询就要花一定时间，一些I/O事件得不到及时响应。
我曾经参与的一个项目使用了reactor架构，设计只支持一个连接，所以，select花的时间不多，但发送和接收数据量比较大，性能测试时，性能瓶颈是收发线程，最后，只有启动多个进程来解决问题。
reactor框架有上面一些缺陷，自然想到了proactor框架，proactor底层采用异步I/O技术，据说可以显著提高系统性能，所以，本人在hp-unix平台下对reactor和proactor进行了性能对比测试，但遗憾的是，proactor输了。
测试平台：hp-unix ia64
测试场景：在相同的网络压力下，比较两个框架的响应及时率和占用的系统资源。
测试步骤：
1.启动proactor和reactor服务端，分别在不同的端口监听连接
2.启动客户端，分别向proactor,reactor发送数据，压力相同；
3.观察服务端的及时响应统计数据；
4.观察资源使用情况。
测试结果：
1.reactor和proactor的及时响应率基本相同，相差不超过1%；
2.proactor占用了大约50%的系统资源，相比之下，reactor占用的不到5%;
测试总结：
1.在连接较少的系统，reactor的处理能力比proactor高。 simple rule, don't use proactor.
页:
[1]