超高性能网络编程, Asynchronous network I/O

qsc555

好帖，顶一下，比较有兴趣，学习ing,继续看大家讨论

cookis

原帖由 unixpm 于 2008-7-18 17:12 发表

这10000个连接全部都有数据，你还是得遍历一把进行处理，

为什么要遍历一把.. epoll已经将活动的句柄全部返回了..剩下的是你自己定位的算法问题了..是遍历还是用fd索引

黑白人字拖

为什么，openbsd 那么分散？

BoyAir

显然epool写错了。
应该是epoll

netchecking

还是2.6好呀

Kendiv

实际的说，基于Generic OS（Linux/*nix/Windows）的Network I/O都存在理论速度上限的瓶颈，因为OS自身的开销（任务切换，虚拟内存转换等），总线的时延，较低的总线带宽等等都会大幅降低I/O性能，而这是软件本身无法解决的硬伤。

如果你的方案确实需要处理非常大的流量，比如LZ前面提到的H3C的产品，建议还是采用硬件方案（NP、FPGA etc)

个人认为，纯软件的方式，要想让实际处理能力接近理论值，是非常困难的，即使达到了，过低的收益比也会大幅度降低其价值。

LZ提及的 "H3C UMS9005"从其官方资料推测来看，应该是基于H3C or HW某款较高端的数通产品开发而成的，通常这样的产品都是基于NP架构的（网络流量由快速的数据面处理，各个线路板之间采用高速交换网进行数据交换），和你提到的AIO没有啥关系，放在一起比没有任何意义。

另外基于Linux/*nix的纯软件方案，在高可靠性(HA)上有其致命的硬伤，不可能用在关键业务上。

fm971

原帖由 unixpm 于 2008-7-18 17:13 发表
呵呵，我现在做的东西跟楼主做的几乎一样，也是交换数据的，说说自己的一些看法。

(1) I/O 模型的选择，

epoll就一定好吗?  epoll最有用的就是ET模式，适合于那种有大量连接，但是有数据连接有限的情况， ...

不错.  有两个点很值得关注,  contect-switches, IP 分片.

cookis

原帖由 Kendiv 于 2008-7-20 16:01 发表
实际的说，基于Generic OS（Linux/*nix/Windows）的Network I/O都存在理论速度上限的瓶颈，因为OS自身的开销（任务切换，虚拟内存转换等），总线的时延，较低的总线带宽等等都会大幅降低I/O性能，而这是软件本身 ...

确实.. 软件费半天劲优化, 有时还不如多花点儿钱升级一下设备.

Kendiv

原帖由 fm971 于 2008-7-21 09:53 发表
... 每块板最大8Gbps。如果软件方案也接近8Gbps，就有得比了。
软件方案相对来说是有它的可靠性等劣势。但是像OS里的TCP/IP协议栈也属于软件，可靠性是能经受考验的。

嗯，软件达到8Gbps?? 你用8块1G的网卡？ 还是10块？ 使用普通的小型机吗？（1U/2U）？？？ 那种分时复用的总线机制能达到8*1G=8Gbit?

还有，我所指的可靠性并不是指协议栈是否可靠，比如当设备在线时，如果某个网口突然down掉，你如何处理？系统关键组件死掉后，是否能及时自动启动/恢复?

还有就是是否能保证业务中断时间始终位于一个下限范围里？等等。

fm971

原帖由 Kendiv 于 2008-7-21 10:27 发表


嗯，软件达到8Gbps?? 你用8块1G的网卡？ 还是10块？ 使用普通的小型机吗？（1U/2U）？？？ 那种分时复用的总线机制能达到8*1G=8Gbit?

还有，我所指的可靠性并不是指协议栈是否可靠，比如当设备在线时，如 ...

你说的没错. 硬件版是有很多优势.  但是要用NP/ASIC架构我不知道要多少成本!

他们的8Gbps也只是理论值.  如果用PC架构的高端服务器, IO能力还是不同的.