先后查看了,和的 相关源码,无一例外,他们一致认为多路复用是性能最好的服务器架构。事实也确实应该如此,进程的出现一方面就是为了保存任务的执行上下文从而简化应用程序 设计,如果程序的逻辑结构不是很复杂,那么用整个进程控制块来保存执行上下文未免有些大材小用,加上进程调度和其他的一些额外开销,程序设计上的高效很可 能会被执行时的低效所抵消。代价也是有的:程序设计工作将更加具有挑战性。
体系结构选定之后,我们就要考虑更加细节的部分,比如说用什么操作系统,用操作系统提供的那些API。在这方面,前辈们已经做过很多,我们只需要简单的“拿来”即可,如果再去枉费唇舌,简直就是浪费时间,图财害命。从根本上分析了导致服务器低效的罪魁祸首:数据拷贝、(用户和内核)上下文切换、内存申请(管理)和锁竞争;列举并分析了UNIX、Linux甚至是部分Windows为提高服务器性能而设计的一些系统调用接口,这篇文档的难能可贵之处还在于它一致保持更新;更是通过实测数据用图表的形式把BSD和Linux的相关系统调用的性能直观地陈列在我们眼前,结果还是令人激动的:Linux 2.6的相关系统调用的时间复杂度竟然是O(1)。简单的总结如下:- 操作系统采用Linux 2.6.x内核,不仅因为它的高性能,更因为它大开源(这并不是说其他的UNIX或者是BSD衍生物不开源)给程序设计带来的便利,我们甚至可以把服务做到内核空间。
- 多路复用采用epoll的“电平触发”(Level Triggered)模式,必要时可以采用“边缘触发”(Edge Triggered),但要注意防止数据停滞。
- 为避免数据拷贝可以采用sendfile系统调用发送小文件,或者是文件的小部分,注意避免sendfile因磁盘IO而导致的阻塞。
- 如果服务操作设计大量磁盘IO操作,应选用,其对应的用户空间库为libaio,注意:这里提到异步IO库并非目前glibc中附带的异步IO实现。
- 如果同时有多个数据需要传输,采用writev/readv来减少系统调用所带来的上下文切换开销,如果数据要写到网络套接字文件描述符,这也能在一定程度上防止网络上出现比较小帧,为此,还可以有选择地开启TCP_CORK选项。
- 实现自己的内存管理,比如说缓存数据,复用常用数据结构等。
- 用多线程替代多进程,线程库当然选择nptl。
- 避免进程/线程间非必要的同步,保持互斥区的短小。