在 “Nginx 0.7.x + PHP 5.2.10(FastCGI)搭建支持高并发量的Web服务器 ”文章提到过:为什么Nginx的性能要比Apache高得多这一问题。这主要是因为Nginx使用了最新的epoll(Linux 2.6内核)和kqueue(FreeBSD)网络I/O模型,而Apache则使用的是传统的select模型。曾在一篇博客上看到有这么个实例:
假设你在大学中读书,要等待一个朋友来访,而这个朋友只知道你在A号楼,但是不知道你具体住在哪里,于是你们约好了在A号楼门口见面.如果你使用的阻塞IO 模型来处理这个问题,那么你就只能一直守候在A号楼门口等待朋友的到来,在这段时间里你不能做别的事情,不难知道,这种方式的效率是低下的.现在时代变化了,开始使用多路复用IO模型来处理这个问题.你告诉你的朋友来了A号楼找楼管大妈,让她告诉你该怎么走.这里的楼管大妈扮演的就是多路复用IO的角色。
解释select和epoll模型的工作方式:
select版大妈做的是如下的事情:比如同学甲的朋友来了,select版大妈比较笨,她带着朋友挨个房间进行查询谁是同学甲,你等的朋友来了。如果每到来一个朋友楼管大妈都要全楼的查询同学,那么处理的效率必然就低下了,过不久楼底就有不少的人了。
epoll版大妈就比较先进了,她记下了同学甲的信息,比如说他的房间号,那么等同学甲的朋友到来时,只需要告诉该朋友同学甲在哪个房间即可,不用自己亲自带着人满大楼的找人了。epoll大妈可以不用吹灰之力就可以定位到同学甲。一看就很明白 epoll和select 模型的区别了吧。
在Linux内核中,select所用到的FD_SET是有限的,即内核中有个参数__FD_SETSIZE定义了每个FD_SET的句柄个数,在内核源码中 /usr/include/linux/posix_types.h 中
#undef __FD_SETSIZE
#define __FD_SETSIZE 1024
如果想要同时检测1025个句柄的可读状态或 可写状态 ,select是不能实现的。在内核中实现select是使用轮询方法,即每次检测都会遍历所有FD_SET中的句柄,显然,select函数的执行时间与 FD检测的句柄数越多就会越费时。
epoll是多路复用IO(I/O Multiplexing) 中的一种方式,仅用于linux2.6以上内核。而epoll模型它所支持的FD上限是最大可以打开文件的数目,这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右,具体请查看:cat /proc/sys/fs/file-max ,这个数目和系统内存关系很大。
传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合,不过由于网络延时,任一时间只有部分的socket是"活跃"的,但是select/poll每次调用都会线性扫描全部的集合,导致效率呈现线性下降。但是epoll不存在这个问题,它只会对"活跃"的socket进行操作---这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么,只有"活跃"的socket才会主动的去调用 callback函数,其他idle状态socket则不会,在这点上,epoll实现了一个"伪"AIO,因为这时候推动力在os内核。在一些 benchmark中,如果所有的socket基本上都是活跃的---比如一个高速LAN环境,epoll并不比select/poll有什么效率,相反,如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。
epoll有两种工作模式:Edge Triggered (ET)、Level Triggered (LT)
LT(level triggered)是缺省的工作方式,并且同时支持block和no-block socket.在这种做法中,内核告诉你一个文件描述符是否就绪了,然后可以对这个就绪的fd进行IO操作。如果你不作任何操作,内核还是会继续通知你的,所以,这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表。
ET (edge-triggered)是高速工作方式,只支持no-block socket。在这种模式下,当描述符从未就绪变为就绪时,内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪,并且不会再为那个文件描述符发送更多的就绪通知,直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如,你在发送,接收或者接收请求,或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误)。
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/ctowoo/archive/2009/10/01/4626140.aspx
分享到:
相关推荐
Linux服务器网络开发模型.docx
Linux服务器开发: 1. 算法与设计模式专栏 2. 后台组件编程专栏 3. 基础组件开发专栏 4. 开源框架 5. 网络服务 6. 性能测试 7. 代码工程化 8. 互联网云盘项目 高级架构 1. 源码分析 2. 中间件开发 3. Linux内核 4....
(牛客网C++课程)Linux 高并发Web服务器项目实战(带定时检测代码) 技术框架: 1. 线程池 + 非阻塞 socket + epoll + 事件处理的并发模型 2. 状态机解析HTTP请求 3. 心跳机制 4. 简易日志系统 主要内容: 1. ...
电子书下载 : ...本书的主要内容:网络的基本原理、UNIX套接字编辑、Winsock编程、游戏服务器编程、游戏服务器编程开发模型、用于插件式游戏的基本模块的开发、网络程序库。
服务器属于客户端服务器模式,通过网络传输串口数据流.服务器基于嵌入式Linux的TCP/IP,通过串行接口的转换,以非阻塞方式进行数据收发,并实现了心跳方式的连接中断检测.经仿真和硬件测试,服务器运行稳定,可挂接串口...
Easy-Reactor是一个基于Reactor模式的Linux C++网络服务器框架,支持多线程TCP服务器,单线程TCP服务器,单线程UDP服务器等形式,可以让使用者完全专注于业务,快速开发出一个高效的服务器应用。 在工作中开发基础...
最近需要训练一个生成对抗网络模型,然后开发接口,不得不在一台有显卡的远程linux服务器上进行,所以,趁着这个机会研究了下怎么使用vscode来进行远程开发。 (1)在windows系统命令行下运行命令:ssh-keygen, ...
本书是Linux服务器编程领域的经典著作,由资深Linux软件开发工程师撰写,从网络协议、服务器编程核心要素、原理机制、工具框架等多角度全面阐释了编写高性能Linux服务器应用的方法、技巧和思想。不仅理论全面、深入...
在网络程序里面,一般来说都是许多客户对应一个服务器,为了处理客户的请求,对服务端的程序就提出了特殊的要求。 目前最常用的服务器模型有: •循环服务器:服务器在同一时刻只能响应一个客户端的请求 •并发...
本书主要讲述采用现代C++ 在x86-64 Linux 上编写多线程TCP 网络服务程序的主流常规技术,重点讲解一种适应性较强的多线程服务器的编程模型,即one loop per thread。这是在Linux 下以native 语言编写用户态高性能...
基于主动队列管理的Linux并发服务器模型及负载均衡算法的研究.pdf
《Linux多线程服务端编程:使用muduo C++网络库》主要讲述采用现代C++在x86-64 Linux上编写多线程TCP网络服务程序的主流常规技术,重点讲解一种适应性较强的多线程服务器的编程模型,即one loop per thread。...
Linux下一种多核网络服务器模型设计与实现.pdf
LINUX虚拟服务器集群模型及其任务分配算法的探讨.pdf
linux下多线程文件服务器 http://blog.csdn.net/ce123_zhouwei/article/details/17066313文章的附件
远程控制Linux服务器的模式方法及其性能分析.pdf
基于libevent开发的网页服务器,技术支持高并发多路转接IO模型,反应堆,线程池等技术,学习应用两不误!
本书主要讲述采用现代C++...这是在Linux 下以native 语言编写用户态高性能网络程序最成熟的模式,掌握之后可顺利地开发各类常见的服务端网络应用程序。本书以muduo 网络库为例,讲解这种编程模型的使用方法及注意事项。
嵌入式Linux开发