首先承认这个标题标题党了:)。在上次的FreeBSD和linux的nginx静态文件性能对比测试 后,我萌发了自己动手做一个简单的Web Server来搞清楚nginx高性能背后的原理的想法。最后成功实现了一个基于epoll的简单的HTTP服务器,实现了200,404,400,304响应,并且性能比nginx高了一点点。本文主要介绍这个HTTP服务器的原理和设计过程。
阅读了一些文章(见最后的参考阅读)后,我整理出了以下要点:
实现多并发的socket服务器有这样几个方法:
1. 多进程共享一个监听端口
bind之后使用fork()创建一份当前进程的拷贝,并启动子进程。子进程采用阻塞式accept、read、write,即这些操作会阻塞线程,直到操作完成才继续执行。缺点是进程之间通信速度慢,每个进程占用很多内存,所以并发数一般受限于进程数。
2. 多线程
类似多进程,只不过用线程代替了进程。主线程负责accept,为每个请求建立一个线程(或者使用线程池复用线程)。比多进程速度快,占用更少的内存,稳定性不及多进程。因为每个线程都有自己的堆栈空间,其占用的内存还是无法免除的,所以并发数一般受限于线程数。
一个阻塞式IO程序的流程示例图:
3. 事件驱动的非阻塞IO(nonblocking I/O)
单线程,将socket设置为非阻塞模式(accept、read、write会立即返回。如果已经accept完了所有的连接,或读光了缓冲区的数据,或者写满了缓冲区,会返回-1,而不是进入阻塞状态)。使用select或epoll等机制,同时监听多个IO操作有无事件发生。当其中的一个或多个处于Ready状态(即:监听的socket可以accept,tcp连接可以read等)后,立即处理相应的事件,处理完后立即回到监听状态(注意这里的监听是监听IO事件,不是监听端口)。相当于阻塞式IO编程中任意一处都可能回到主循环中继续等待,并能从等待中直接回到原处继续执行;而accept、读、写都不再阻塞,阻塞全部移动到了一个多事件监听操作中。
一个非阻塞式IO程序的流程示例图:
举例来说,如果在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例子作为参考,然后在它的基础上边修改边做实验:
这个例子比较简单,而且也没有体现出非阻塞IO编程。不过通过它我了解到了epoll的基本使用方法。为了实现并发通信,我们需要把程序“摊平”。
首先,分析我们的HTTP服务器通信过程用到的变量:
然后,定义一个结构用于保存这些变量:
为了简便,我直接用一个全局数组装所有的process:
另外定义每个连接通信过程中的三个状态:
之后,就是按部就班地实现主循环、读取request,解析header,判断文件是否存在、检查文件修改时间,发送相应的header和content了。
下面只把程序中跟epoll有关的关键部分贴出来:
main()函数:
使用epoll_create()创建一个epoll fd,注意,这里的listen_sock已经设置为nonblocking(我使用了这篇文章中的setNonblocking函数)了:
这里的EPOLLIN表示监听“可读”事件。
在主循环中epoll_wait():
epoll_wait()会在发生事件后停止阻塞,继续执行,并把发生了事件的event的file descriptor放入events中,返回数组大小。注意的是,这里要循环处理所有的fd。
接下来是关键部分:
根据epoll返回的fd,做不同处理:如果是监听的socket,则accept();否则,根据sock的fd查找相应的process结构体,从中取回状态信息,返回到之前的处理状态中。这样就能实现信春哥,死后原地复活的状态恢复机制了。
在accept中,将accept出来的连接也设置为非阻塞,然后在process数组中找一个还没使用的空位,初始化,然后把这个socket存到process结构体中:
三个不同状态对应三个不同函数进行处理,我就不全贴了,以read_request为例:
这里的注意点如下:
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对比:
结果很令人欣慰的比nginx快了一点点,并且只用了700K内存。不过作为一个功能比nginx少了很多的程序来说这一结果是意料之中的。
然后试图测试上万并发的情况,结果too many open files了。于是修改fd数限制:
再次测试:
nginx设置worker_connections 20480以后:
结果性能只下降了一点点,并且依然领先nginx。不过,为了承受更多的连接调大process数组以后,进程一共吃了40M内存。而nginx仅用了5M内存。因为我们使用了极其浪费内存的用数组装连接状态和缓存的方法,所以会吃掉缓存大小(process.buf的大小)乘以process数组的大小的内存。调小缓存以后内存占用降到6M,不过这并不是根本解决之道,还是存在很大的浪费。如果改为动态内存管理,应该就会小于nginx了。
这说明事件驱动的非阻塞IO可以顶得住上万并发,并需要远小于阻塞式编程的服务器程序的内存,速度也更快。
最后把源码丢到github了,想看完整源码的同学请移步:
参考阅读:
- 海报