浅析Linux服务器网络开发模型

服务器
自己又一次动心想装一个liunx系统使用,可是还没有敢这样做,采用linux系统实在是太浪费精力了,很多东西要自己设置。

几日前,公司同事将笔记本系统转成了liunx系统,看上去不错,应该有的应用基本上都有了。如文档处理软件、表格处理软件、eclipse开发环境等。别说,还真不错。自己又一次动心想装一个liunx系统使用,可是还没有敢这样做,采用linux系统实在是太浪费精力了,很多东西要自己设置。

为什么Nginx的性能要比Apache高得多?

这主要是因为Nginx使用了***的epoll(Linux 2.6内核)和kqueue(FreeBSD)网络I/O模型,而Apache则使用的是传统的select模型。曾在一篇博客上看到有这么个实例:

假设你在大学中读书,要等待一个朋友来访,而这个朋友只知道你在A号楼,但是不知道你具体住在哪里,于是你们约好了在A号楼门口见面.如果你使用的阻塞IO 模型来处理这个问题,那么你就只能一直守候在A号楼门口等待朋友的到来,在这段时间里你不能做别的事情,不难知道,这种方式的效率是低下的.现在时代变化了,开始使用多路复用IO模型来处理这个问题.你告诉你的朋友来了A号楼找楼管大妈,让她告诉你该怎么走.这里的楼管大妈扮演的就是多路复用IO的角色。

[[238404]]

解释select和epoll模型的工作方式:

select版大妈做的是如下的事情:比如同学甲的朋友来了,select版大妈比较笨,她带着朋友挨个房间进行查询谁是同学甲,你等的朋友来了。如果每到来一个朋友楼管大妈都要全楼的查询同学,那么处理的效率必然就低下了,过不久楼底就有不少的人了。

epoll版大妈就比较先进了,她记下了同学甲的信息,比如说他的房间号,那么等同学甲的朋友到来时,只需要告诉该朋友同学甲在哪个房间即可,不用自己亲自带着人满大楼的找人了。epoll大妈可以不用吹灰之力就可以定位到同学甲。一看就很明白 epoll和select 模型的区别了吧。

在Linux内核中,select所用到的FD_SET是有限的,即内核中有个参数__FD_SETSIZE定义了每个FD_SET的句柄个数,在内核源码中 /usr/include/linux/posix_types.h 中

  1. #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 错误)。

责任编辑:武晓燕 来源: 搜狐
相关推荐

2009-07-06 14:05:11

JSP服务器

2010-08-31 17:37:22

DHCP服务器故障

2010-09-14 11:33:39

Linux下设置tft

2010-05-25 09:32:04

搭建SVN服务器

2009-12-03 17:43:27

Linux服务器

2009-08-06 10:49:45

ASP.NET服务器控

2020-09-23 14:20:07

Kubernetes容器网络模型

2009-10-10 09:06:35

服务器测试方案

2009-07-06 17:34:38

JSP HTTP服务器

2010-07-30 18:12:22

2011-03-23 13:59:43

2011-08-01 13:10:58

2010-04-08 17:43:44

Unix操作系统

2011-02-22 11:23:48

vsFTPDLinux服务器

2009-08-21 17:33:34

服务器端程序C#网络编程

2009-08-21 17:39:20

服务器端程序C#网络编程

2011-11-08 13:12:29

Linux系统网络服务器并发服务器

2011-11-10 09:40:20

Linux网络服务模型

2019-01-15 08:12:56

Linux服务器标配

2011-02-22 11:23:48

vsFTPDLinux服务器
点赞
收藏

51CTO技术栈公众号