实现了一个比nginx速度更快的HTTP服务器

标签: nginx 速度 快的 | 发表时间:2011-09-23 16:34 | 作者:clowwindy jyf1987
出处:http://www.cnblogs.com/clowwindy/

首先承认这个标题标题党了:)。在上次的FreeBSD和linux的nginx静态文件性能对比测试 后,我萌发了自己动手做一个简单的Web Server来搞清楚nginx高性能背后的原理的想法。最后成功实现了一个基于epoll的简单的HTTP服务器,实现了200,404,400,304响应,并且性能比nginx高了一点点。本文主要介绍这个HTTP服务器的原理和设计过程。

阅读了一些文章(见最后的参考阅读)后,我整理出了以下要点:

实现多并发的socket服务器有这样几个方法:

1. 多进程共享一个监听端口

bind之后使用fork()创建一份当前进程的拷贝,并启动子进程。子进程采用阻塞式accept、read、write,即这些操作会阻塞线程,直到操作完成才继续执行。缺点是进程之间通信速度慢,每个进程占用很多内存,所以并发数一般受限于进程数。

2. 多线程

类似多进程,只不过用线程代替了进程。主线程负责accept,为每个请求建立一个线程(或者使用线程池复用线程)。比多进程速度快,占用更少的内存,稳定性不及多进程。因为每个线程都有自己的堆栈空间,其占用的内存还是无法免除的,所以并发数一般受限于线程数。

一个阻塞式IO程序的流程示例图:

QQ截图20110923131031

 

3. 事件驱动的非阻塞IO(nonblocking I/O)

单线程,将socket设置为非阻塞模式(accept、read、write会立即返回。如果已经accept完了所有的连接,或读光了缓冲区的数据,或者写满了缓冲区,会返回-1,而不是进入阻塞状态)。使用select或epoll等机制,同时监听多个IO操作有无事件发生。当其中的一个或多个处于Ready状态(即:监听的socket可以accept,tcp连接可以read等)后,立即处理相应的事件,处理完后立即回到监听状态(注意这里的监听是监听IO事件,不是监听端口)。相当于阻塞式IO编程中任意一处都可能回到主循环中继续等待,并能从等待中直接回到原处继续执行;而accept、读、写都不再阻塞,阻塞全部移动到了一个多事件监听操作中。

一个非阻塞式IO程序的流程示例图:

 

QQ截图20110923131039

举例来说,如果在A连接的Read request的过程中,缓冲区数据读完了,而请求还没有结束,直接返回到主循环中监听其它事件。而这时如果发现另一个Send了一半的Response连接B变为了可写状态,则直接处理B连接Send Response事件,从上次B连接写了一半的地方开始,继续写入数据。这样一来,虽然是单线程,但A和B同时进行,互不干扰。

因为流程更加复杂,无法依靠线程的堆栈保存每个连接处理过程中的各种状态信息,我们需要自己维护它们,这种编程方式需要更高的技巧。比方说,原先我们可以在send_response函数中用局部变量保存发送数据的进度,而现在我们只能找一块其它的地方,为每一个连接单独保存这个值了。

nginx即使用事件驱动的非阻塞IO模式工作。

nginx支持多种事件机制:跨平台的select,Linux的poll和epoll,FreeBSD的kqueue,Solaris的/dev/poll等。在高并发的情况下,在Linux上使用epoll性能最好,或者说select的性能太差了。

事件机制分为水平触发,或译状态触发(level-triggered)和边缘触发(edge-triggered)。前者是用通过状态表示有事件发生,后者通过状态变化表示事件发生。打个比方来说,使用状态触发的时候,只要缓冲区有数据,你就能检测到事件的存在。而使用边缘触发,你必须把缓冲区的数据全部读完之后,才能进行下一次事件的检测,否则,因为状态一直处于可读状态,没有发生变化,你将永远收不到这个事件。显然,后者对编写程序的严谨性要求更高。

select和poll属于前者,epoll同时支持这两种模式。值得一提的是,我自己测试了一下,发现即使在20000并发的情况下,epoll使用这两种模式之前性能差异仍可以忽略不计。

另外需要注意的是,对于常规文件设置非阻塞是不起作用的

4. 此外还有异步IO,一般在Windows上使用,这里就不谈了。

另外nginx使用了Linux的sendfile函数。和传统的用户程序自己read和write不同,sendfile接收两个文件描述符,直接在内核中实现复制操作,相比read和write,可以减少内核态和用户态的切换次数,以及数据拷贝的次数。

接下来正式开始设计。我选择了非阻塞IO,epoll的边缘触发模式。先找了个比较完整的使用epoll的一个socket server例子作为参考,然后在它的基础上边修改边做实验:

https://banu.com/blog/2/how-to-use-epoll-a-complete-example-in-c/

这个例子比较简单,而且也没有体现出非阻塞IO编程。不过通过它我了解到了epoll的基本使用方法。为了实现并发通信,我们需要把程序“摊平”。

首先,分析我们的HTTP服务器通信过程用到的变量:

状态

Wait for reading

Wait for writing

次数

变量类型

非本地变量

备注

Accept

Y

N

n

local

   

Read request

Y

N

n

nonlocal

Read buf

 

Open file

N

N

n

nonlocal

文件名

 

Send response header

N

Y

n

nonlocal

Response header buf

 

Read file -> Send response content

N

Y

n*n

nonlocal

Read&write buf

Write pos

fd

Sock

读满read buf或读到EOF,再发

发送时将read buf

Close file

N

N

n

 

fd

 

Close socket

N

N

n

 

sock

 

然后,定义一个结构用于保存这些变量:

struct process {
int sock;
int status;
int response_code;
int fd;
int read_pos;
int write_pos;
int total_length;
char buf[BUF_SIZE];
};

为了简便,我直接用一个全局数组装所有的process:

static struct process processes[MAX_PORCESS];

另外定义每个连接通信过程中的三个状态:

#define STATUS_READ_REQUEST_HEADER    0
#define STATUS_SEND_RESPONSE_HEADER 1
#define STATUS_SEND_RESPONSE 2

之后,就是按部就班地实现主循环、读取request,解析header,判断文件是否存在、检查文件修改时间,发送相应的header和content了。

下面只把程序中跟epoll有关的关键部分贴出来:

main()函数:

使用epoll_create()创建一个epoll fd,注意,这里的listen_sock已经设置为nonblocking(我使用了这篇文章中的setNonblocking函数)了:

    efd = epoll_create1 ( 0 );
if ( efd == -1 )
{
...
}

event.data.fd = listen_sock;
event.events = EPOLLIN | EPOLLET;
s = epoll_ctl ( efd, EPOLL_CTL_ADD, listen_sock, &event );
if ( s == -1 )
{
...
}

/* Buffer where events are returned */
events = calloc ( MAXEVENTS, sizeof event );

这里的EPOLLIN表示监听“可读”事件。

在主循环中epoll_wait():

    while ( 1 )
{
int n, i;

n = epoll_wait ( efd, events, MAXEVENTS, -1 );
if ( n == -1 )
{
perror ( "epoll_wait" );
}
for ( i = 0; i < n; i++ )
{
if ( ( events[i].events & EPOLLERR ) ||
( events[i].events & EPOLLHUP ) )
{
fprintf ( stderr, "epoll error\n" );
close ( events[i].data.fd );
continue;
}

handle_request ( events[i].data.fd );

}
}

epoll_wait()会在发生事件后停止阻塞,继续执行,并把发生了事件的event的file descriptor放入events中,返回数组大小。注意的是,这里要循环处理所有的fd。


接下来是关键部分:

void handle_request ( int sock )
{
if ( sock == listen_sock )
{
accept_sock ( sock );
}
else
{
struct process* process = find_process_by_sock ( sock );
if ( process != 0 )
{
switch ( process->status )
{
case STATUS_READ_REQUEST_HEADER:
read_request ( process );
break;
case STATUS_SEND_RESPONSE_HEADER:
send_response_header ( process );
break;
case STATUS_SEND_RESPONSE:
send_response ( process );
break;
default:
break;
}
}
}
}

根据epoll返回的fd,做不同处理:如果是监听的socket,则accept();否则,根据sock的fd查找相应的process结构体,从中取回状态信息,返回到之前的处理状态中。这样就能实现信春哥,死后原地复活的状态恢复机制了。

在accept中,将accept出来的连接也设置为非阻塞,然后在process数组中找一个还没使用的空位,初始化,然后把这个socket存到process结构体中:

struct process* accept_sock ( int listen_sock )
{
int s;
// 在ET模式下必须循环accept到返回-1为止
while ( 1 )
{
struct sockaddr in_addr;
socklen_t in_len;
int infd;
char hbuf[NI_MAXHOST], sbuf[NI_MAXSERV];
if ( current_total_processes >= MAX_PORCESS )
{
// 请求已满,accept之后直接挂断
infd = accept ( listen_sock, &in_addr, &in_len );
if ( infd == -1 )
{
if ( ( errno == EAGAIN ) ||
( errno == EWOULDBLOCK ) )
{
break;
}
else
{
perror ( "accept" );
break;
}
}
close ( infd );

return;
}

in_len = sizeof in_addr;
infd = accept ( listen_sock, &in_addr, &in_len );
if ( infd == -1 )
{
if ( ( errno == EAGAIN ) ||
( errno == EWOULDBLOCK ) )
{
break;
}
else
{
perror ( "accept" );
break;
}
}

getnameinfo ( &in_addr, in_len,
hbuf, sizeof hbuf,
sbuf, sizeof sbuf,
NI_NUMERICHOST | NI_NUMERICSERV );

//设置为非阻塞
s = setNonblocking ( infd );
if ( s == -1 )
abort ();
int on = 1;
setsockopt ( infd, SOL_TCP, TCP_CORK, &on, sizeof ( on ) );
//添加监视sock的读取状态
event.data.fd = infd;
event.events = EPOLLIN | EPOLLET;
s = epoll_ctl ( efd, EPOLL_CTL_ADD, infd, &event );
if ( s == -1 )
{
perror ( "epoll_ctl" );
abort ();
}
struct process* process = find_empty_process_for_sock ( infd );
current_total_processes++;
reset_process ( process );
process->sock = infd;
process->fd = NO_FILE;
process->status = STATUS_READ_REQUEST_HEADER;
}
}

三个不同状态对应三个不同函数进行处理,我就不全贴了,以read_request为例:

void read_request ( struct process* process )
{
int sock = process->sock, s;
char* buf=process->buf;
char read_complete = 0;

ssize_t count;

while ( 1 )
{
count = read ( sock, buf + process->read_pos, BUF_SIZE - process->read_pos );
if ( count == -1 )
{
if ( errno != EAGAIN )
{
handle_error ( process, "read request" );
return;
}
else
{
//errno == EAGAIN表示读取完毕
break;
}
}
else if ( count == 0 )
{
// 被客户端关闭连接
cleanup ( process );
return;
}
else if ( count > 0 )
{
process->read_pos += count;
}
}

int header_length = process->read_pos;
// determine whether the request is complete
if ( header_length > BUF_SIZE - 1 )
{
process->response_code = 400;
process->status = STATUS_SEND_RESPONSE_HEADER;
strcpy ( process->buf, header_400 );
send_response_header ( process );
handle_error ( processes, "bad request" );
return;
}
buf[header_length]=0;
read_complete = ( strstr ( buf, "\n\n" ) != 0 ) || ( strstr ( buf, "\r\n\r\n" ) != 0 );

if ( read_complete )
{
// ...

//解析之后,打开文件,把文件描述符存入process,然后进入发送header状态
process->status = STATUS_SEND_RESPONSE_HEADER;
//修改此sock的监听状态,改为监视写状态
event.data.fd = process->sock;
event.events = EPOLLOUT | EPOLLET;
s = epoll_ctl ( efd, EPOLL_CTL_MOD, process->sock, &event );
if ( s == -1 )
{
perror ( "epoll_ctl" );
abort ();
}
//发送header
send_response_header ( process );
}
}

这里的注意点如下:

1. 读取的时候要一直循环读取到返回-1为止,然后检查errno,如果errno为EAGAIN,表示缓冲区已经空了,这个socket变为了“不可读”。如果不读完,边缘触发模式的epoll_wait将永远不会再触发这个socket的“可读”事件。

2. 使用epoll_ctl ( efd, EPOLL_CTL_MOD, process->sock, &event )修改epoll的状态,这里在读完后,我们要继续监听“可写”事件,因此要把epoll监听的事件改为EPOLLOUT。

接下来不断完善这个程序并进行优化,并实现了304 not modified功能之后,用ab测试性能,并和nginx对比:

Server Software:        clowwindyserver/1.0
Server Hostname: localhost
Server Port: 8082

Document Path: /jquery.js
Document Length: 57244 bytes

Concurrency Level: 100
Time taken for tests: 2.241 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 574420000 bytes
HTML transferred: 572440000 bytes
Requests per second: 4462.88 [#/sec] (mean)
Time per request: 22.407 [ms] (mean)
Time per request: 0.224 [ms] (mean, across all concurrent requests)
Transfer rate: 250348.23 [Kbytes/sec] received

Server Software:        nginx/0.7.67
Server Hostname: localhost
Server Port: 80

Document Path: /jquery.js
Document Length: 57244 bytes

Concurrency Level: 100
Time taken for tests: 2.490 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 574720000 bytes
HTML transferred: 572440000 bytes
Requests per second: 4016.54 [#/sec] (mean)
Time per request: 24.897 [ms] (mean)
Time per request: 0.249 [ms] (mean, across all concurrent requests)
Transfer rate: 225428.04 [Kbytes/sec] received

结果很令人欣慰的比nginx快了一点点,并且只用了700K内存。不过作为一个功能比nginx少了很多的程序来说这一结果是意料之中的。
然后试图测试上万并发的情况,结果too many open files了。于是修改fd数限制:

# echo 32768 > /proc/sys/fs/file-max
# ulimit -n 32768

再次测试:

Server Software:        clowwindyserver/1.0
Server Hostname: localhost
Server Port: 8082

Document Path: /jquery.js
Document Length: 57244 bytes

Concurrency Level: 10000
Time taken for tests: 2.249 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 574420000 bytes
HTML transferred: 572440000 bytes
Requests per second: 4445.59 [#/sec] (mean)
Time per request: 2249.420 [ms] (mean)
Time per request: 0.225 [ms] (mean, across all concurrent requests)
Transfer rate: 249378.52 [Kbytes/sec] received

nginx设置worker_connections  20480以后:

Server Software:        nginx/0.7.67
Server Hostname: localhost
Server Port: 80

Document Path: /jquery.js
Document Length: 57244 bytes

Concurrency Level: 10000
Time taken for tests: 2.715 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 574720000 bytes
HTML transferred: 572440000 bytes
Requests per second: 3683.83 [#/sec] (mean)
Time per request: 2714.569 [ms] (mean)
Time per request: 0.271 [ms] (mean, across all concurrent requests)
Transfer rate: 206754.74 [Kbytes/sec] received


结果性能只下降了一点点,并且依然领先nginx。不过,为了承受更多的连接调大process数组以后,进程一共吃了40M内存。而nginx仅用了5M内存。因为我们使用了极其浪费内存的用数组装连接状态和缓存的方法,所以会吃掉缓存大小(process.buf的大小)乘以process数组的大小的内存。调小缓存以后内存占用降到6M,不过这并不是根本解决之道,还是存在很大的浪费。如果改为动态内存管理,应该就会小于nginx了。

这说明事件驱动的非阻塞IO可以顶得住上万并发,并需要远小于阻塞式编程的服务器程序的内存,速度也更快。

最后把源码丢到github了,想看完整源码的同学请移步:

https://github.com/clowwindy/clowwindy_server

 

参考阅读:

The C10K problem (强烈推荐)

Introduction to non-blocking I/O

Non-blocking I/O with regular files

Linux Files and the Event Poll Interface

作者: clowwindy 发表于 2011-09-23 16:34 原文链接

评论: 10 查看评论 发表评论


最新新闻:
· 暗黑3再次跳票:最早于2012年初发布(2011-09-23 22:58)
· comScore:亚太地区成全球最大社交网络市场(2011-09-23 22:32)
· 谷歌或将关闭电商网站Boutiques.com(2011-09-23 22:30)
· 乔布斯:1997年就看好云计算(2011-09-23 22:05)
· 七大要点让你对 Facebook f8 大会一目了然(2011-09-23 22:00)

编辑推荐:中国的土壤真的不适合软件生长!

网站导航:博客园首页  我的园子  新闻  闪存  小组  博问  知识库

相关 [nginx 速度 快的] 推荐:

实现了一个比nginx速度更快的HTTP服务器

- jyf1987 - 博客园-clowwindy的杂草牧场
在上次的FreeBSD和linux的nginx静态文件性能对比测试 后,我萌发了自己动手做一个简单的Web Server来搞清楚nginx高性能背后的原理的想法. 最后成功实现了一个基于epoll的简单的HTTP服务器,实现了200,404,400,304响应,并且性能比nginx高了一点点. 本文主要介绍这个HTTP服务器的原理和设计过程.

nginx配置ssl

- - 邢红瑞的blog
先生成网关证书 ,仿照CA模式.

Nginx安装

- - 企业架构 - ITeye博客
nginx可以使用各平台的默认包来安装,本文是介绍使用源码编译安装,包括具体的编译参数信息. 正式开始前,编译环境gcc g++ 开发库之类的需要提前装好,这里默认你已经装好. ububtu平台编译环境可以使用以下指令. centos平台编译环境使用如下指令. 一般我们都需要先装pcre, zlib,前者为了重写rewrite,后者为了gzip压缩.

Nginx GZip 压缩

- - 开心平淡对待每一天。热爱生活
  Nginx GZip 模块文档详见: http://wiki.nginx.org/HttpGzipModule 常用配置片段如下:. # 压缩比例,比例越大,压缩时间越长. 默认是1 gzip_types. text/css text/javascript; # 哪些文件可以被压缩 gzip_disable.

Nginx 限流

- - 鸟窝
电商平台营销时候,经常会碰到的大流量问题,除了做流量分流处理,可能还要做用户黑白名单、信誉分析,进而根据用户ip信誉权重做相应的流量拦截、限制流量. Nginx自身有的请求限制模块 ngx_http_limit_req_module、流量限制模块 ngx_stream_limit_conn_module基于令牌桶算法,可以方便的控制令牌速率,自定义调节限流,实现基本的限流控制.

NGINX的流媒体插件 nginx-rtmp-module

- - 开源软件 - ITeye博客
战斗民族俄罗斯人民开发的一款NGINX的流媒体插件,除了直播发布音视频流之外具备流媒体服务器的常见功能. 基于HTTP的FLV/MP4 VOD点播. HLS (HTTP Live Streaming) M3U8的支持. 基于http的操作(发布、播放、录制). 可以很好的协同现有的流媒体服务器以及播放器一起工作.

Nginx content cache Nginx内容缓存

- - CSDN博客推荐文章
原文地址: http://nginx.com/resources/admin-guide/caching/. When caching is enabled NGINX saves responses in the cache on the disk and uses them to respond to clients without proxying the requests..

nginx + memcached session 同步

- - 企业架构 - ITeye博客
squid 缓存疑问 问题归纳:. 1 squid 缓存的数据,何时过期,如何判断缓存的数据已经过期,如何把最新的数据缓入squid 并且替换掉旧的内容. 2 如何判断数据是否应该被缓存. 3 校验失败时,是否给出缓存中旧的内容. 上面的几个问题  都可以通过 squid中的 refresh_pattern 配置项 找到答案.

nginx日志切割

- - haohtml's blog
nginx的日志文件没有rotate功能. 如果你不处理,日志文件将变得越来越大,还好我们可以写一个nginx日志切割脚本来自动切割日志文件. 第一步就是重命名日志文件,不用担心重命名后nginx找不到日志文件而丢失日志. 在你未重新打开原名字的日志文件前,nginx还是会向你重命名的文件写日志,linux是靠文件描述符而不是文件名定位文件.

nginx框架总结

- - CSDN博客互联网推荐文章
a、内存池的设计,为一个多级链表结构,本身不负责内存的回收,减少内存碎片,提高内存的利用率,将多次向操作系统申请内存压缩为一次,减少向操作系统申请内存的次数,提高cpu资源的利用;. b、基于事件的master-worker异步处理. 处理事件的机制是由事件分发进程加载事件处理模块来完成与传统将事件提交给handle-thread来处理的方式相比,减少了进程(线程)间的切换,从而降低了请求响应延迟的时间;.