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

cookis

其实在linux平台下异步模型实际都是半同步和半异步这种模式.
epoll还是由单线程来操作的.

键盘老农

freebsd kqueue好用。

fm971

原帖由 键盘老农 于 2008-7-17 12:54 发表
freebsd kqueue好用。

你没看我贴的东西. don't jump to conclusion

fm971

原帖由 converse 于 2008-7-17 11:24 发表
还有这个:
http://pl.atyp.us/content/tech/servers.html

谢谢各各位分享的资料， 这些资料也算讨论的比较深了。

现在缺少的还是Linux aio 和网络的最新资料。Linux本身在这方面也可能没什么进展。socket 这个API都已经用了几个年代了。

键盘老农

原帖由 fm971 于 2008-7-17 13:04 发表


你没看我贴的东西. don't jump to conclusion

想问一下是你自己测出来的吗，还是传说。其他我不会相信。

zsniper

LZ发的那些BSD和Linux的比较已经很老了

现在FreeBSD7.0出来了，多线程以及userland的jemalloc性能已经相当强了。

还有请问LZ，是想写个高并发的呢？还是高相应的呢？

高并发的话，只拿着epoll和kqueue是不够了，需要一个非常合理完善的框架。建议看看<POSA2>

其实所谓高性能是在整个框架的性能，而绝对不仅仅是两个系统调用的事。

[ 本帖最后由 zsniper 于 2008-7-17 15:19 编辑 ]

fm971

原帖由 zsniper 于 2008-7-17 15:10 发表
LZ发的那些BSD和Linux的比较已经很老了

现在FreeBSD7.0出来了，多线程以及userland的jemalloc性能已经相当强了。

还有请问LZ，是想写个高并发的呢？还是高相应的呢？

高并发的话，只拿着epoll和kqueue ...

现在最重要的是网络I/O的并发吞吐量问题.  古老的socket API 有性能限制, 像send()和recv()至少需要拷贝一次缓存. 所以才有那么多人讨论AIO和Zero-Copy. 当然还有其它并发性能问题.

这个BSD和Linux的测试是2003年左右.  可以说明当时linux在网络上的领先.  测试还证明OpenBSD根本不适合网络服务器. 当然BSD会有改进.

zsniper

难道现在有什么可以脱离write()和read()的方法吗？？

至少要从mbuf拷贝到用户空间。。如何zero-copy????

AIO只是一种事件通知方法，内核告诉应用程序有数据可读或者有数据可写，之后再read()和write()，难道你能zero-copy??

现在能做的只是在write()和read()的基础上，搭建出高性能的框架~

[ 本帖最后由 zsniper 于 2008-7-17 16:17 编辑 ]

fm971

这就是为什么这么多人讨论研究socket的并发问题和改进方案.
Ulrich Drepper 在论文里提议的方案是直接访问DMA, read()/receive()只需要返回一个DMA内存指针.
这些是研究性内容, 实现思路可以参考.

[ 本帖最后由 fm971 于 2008-7-17 16:42 编辑 ]

zsniper

其实，我觉得高并发的瓶颈在于你上层的实现，而不在于底层的read().

就我看来，花大精力放在上层实现，才有意义。

还有就是，上层实现的时候，出现内存拷贝的情况很多，并不一定要不在乎系统底层的一点性能损失。

当然这是我的愚见，LZ的想法很好，希望能研究出成果来。。。


PS：支持键盘老农 ， 因为kqueue性能真的很好，并且能支持普通文件(我不了解epoll)   。

[ 本帖最后由 zsniper 于 2008-7-17 17:02 编辑 ]