Nginx为何比Apache Httpd高效

 

转载于：http://www.toxingwang.com/linux-unix/linux-basic/1712.html

1、进程、线程？

在回答nginx 为何比apache更高效以前，必需要先熟悉、了解下概念：什么是进程，什么是线程，什么是程序 ，程序的运行方式？

进程：是具备必定独立功能的，在计算机中已经运行的程序的实体。在早期系统中（如linux 2.4之前），进程是基本运做单位。

线程：在支持线程的系统中（如windows，linux2.6）中，线程才是基本的运做单位，而进程只是线程的容器

程序：程序自己只是指令、数据及其组织形式的描述，进程才是程序（那些指令和数据）的真正运行实例。

进程与程序的关系：现代计算机系统可在同一段时间内以进程的形式将多个程序加载到存储器中，并借由时间共享（或称时分复用），以在一个处理器上表现出同时（平行性）运行的感受。一样的，使用多线程技术（多线程即每个线程都表明一个进程内的一个独立执行上下文）的操做系统或计算机架构，一样程序的平行线程，可在多 CPU 主机或网络上真正同时运行（在不一样的CPU上）。

 

2、常见Web服务方式

Web服务器要为用户提供服务，必须以某种方式，工做在某个套接字上。通常Web服务器在处理用户请求是，通常有以下三种方式可选择：多进程方式、多线程方式、异步方式。

2.1 三种工做模型比较：

Web服务器要为用户提供服务，必须以某种方式，工做在某个套接字上。通常Web服务器在处理用户请求是，通常有以下三种方式可选择：多进程方式、多线程方式、异步方式。

• 多进程方式：为每一个请求启动一个进程来处理。因为在操做系统中，生成进程、销毁进程、进程间切换都很消耗CPU和内存，当负载高是，性能会明显下降。

优势： 稳定性！因为采用独立进程处理独立请求，而进程之间是独立的，单个进程问题不会影响其余进程，所以稳定性最好。

缺点： 资源占用！当请求过大时，须要大量的进程处理请求，进程生成、切换开销很大，并且进程间资源是独立的，形成内存重复利用。

• 多线程方式：一个进程中用多个线程处理用户请求。因为线程开销明显小于进程，并且部分资源还能够共享，所以效率较高。

优势：开销较小！线程间部分数据是共享的，且线程生成与线程间的切换所需资源开销比进程间切换小得多。

缺点：稳定性！线程切换过快可能形成线程抖动，且线程过多会形成服务器不稳定。

• 异步方式：使用非阻塞方式处理请求，是三种方式中开销最小的。但异步方式虽然效率高，但要求也高，由于多任务之间的调度若是出现问题，就可能出现总体故障，所以使用异步工做的，通常是一些功能相对简单，但却符合服务器任务调度、且代码中没有影响调度的错误代码存在的程序。

优势：性能最好！一个进程或线程处理多个请求，不须要额外开销，性能最好，资源占用最低。

缺点：稳定性！某个进程或线程出错，可能致使大量请求没法处理，甚至致使整个服务宕机

 

2.2 一个Web请求的处理过程：

1. 客户发起状况到服务器网卡；
2. 服务器网卡接受到请求后转交给内核处理；
3. 内核根据请求对应的套接字，将请求交给工做在用户空间的Web服务器进程
4. Web服务器进程根据用户请求，向内核进行系统调用，申请获取相应资源（如index.html）
5. 内核发现web服务器进程请求的是一个存放在硬盘上的资源，所以经过驱动程序链接磁盘
6. 内核调度磁盘，获取须要的资源
7. 内核将资源存放在本身的缓冲区中，并通知Web服务器进程
8. Web服务器进程经过系统调用取得资源，并将其复制到进程本身的缓冲区中
9. Web服务器进程造成响应，经过系统调用再次发给内核以响应用户请求
10. 内核将响应发送至网卡
11. 网卡发送响应给用户

经过这样的一个复杂过程，一次请求就完成了。

简单来讲就是：用户请求-->送达到用户空间-->系统调用-->内核空间-->内核到磁盘上读取网页资源->返回到用户空间->响应给用户。上述简单的说明了一下，客户端向Web服务请求过程，在这个过程当中，有两个I/O过程，一个就是客户端请求的网络I/O，另外一个就是Web服务器请求页面的磁盘I/O。 下面咱们就来讲说Linux的I/O模型。

3、各类I/O模型详解

经过上面的对链接的处理分析，咱们知道工做在用户空间的web服务器进程是没法直接操做IO的，须要经过系统调用进行，其关系以下：

即进程向内核进行系统调用申请IO，内核将资源从IO调度到内核的buffer中（wait阶段），内核还需将数据从内核buffer中复制（copy阶段）到web服务器进程所在的用户空间，才算完成一次IO调度。这几个阶段都是须要时间的。根据wait和copy阶段的处理等待的机制不一样，可将I/O动做分为以下五种模式：

• 阻塞I/O
• 非阻塞I/O
• I/O复用（select和poll）
• 信号（事件）驱动I/O（SIGIO）
• 异步I/O（aio）

  3.1 I/O模型简介

  这里有必要先解释一下阻塞、非阻塞，同步、异步、I/O的概念。

3.1.1 阻塞和非阻塞:

阻塞和非阻塞指的是执行一个操做是等操做结束再返回，仍是立刻返回。

好比餐馆的服务员为用户点菜，当有用户点完菜后，服务员将菜单给后台厨师，此时有两种方式：

• 第一种：就在出菜窗口等待，直到厨师炒完菜后将菜送到窗口，而后服务员再将菜送到用户手中；
• 第二种：等一会再到窗口来问厨师，某个菜好了没？若是没有先处理其余事情，等会再去问一次；

第一种就是阻塞方式，第二种则是非阻塞的。

3.1.2 同步和异步:

同步和异步又是另一个概念，它是事件自己的一个属性。还拿前面点菜为例，服务员直接跟厨师打交道，菜出来没出来，服务员直接指导，但只有当厨师将菜送到服务员手上，这个过程才算正常完成，这就是同步的事件。一样是点菜，有些餐馆有专门的传菜人员，当厨师炒好菜后，传菜员将菜送到传菜窗口，并通知服务员，这就变成异步的了。其实异步还能够分为两种：带通知的和不带通知的。前面说的那种属于带通知的。有些传菜员干活可能主动性不是很够，不会主动通知你，你就须要时不时的去关注一下状态。这种就是不带通知的异步。

对于同步的事件，你只能以阻塞的方式去作。而对于异步的事件，阻塞和非阻塞都是能够的。非阻塞又有两种方式：主动查询和被动接收消息。被动不意味着必定很差，在这里它偏偏是效率更高的，由于在主动查询里绝大部分的查询是在作无用功。对于带通知的异步事件，二者皆可。而对于不带通知的，则只能用主动查询。

3.1.3 全异步I/O

回到I/O，无论是I仍是O，对外设(磁盘)的访问均可以分红请求和执行两个阶段。请求就是看外设的状态信息（好比是否准备好了），执行才是真正的I/O操做。在Linux 2.6以前，只有“请求”是异步事件，2.6以后才引入AIO（asynchronous I/O ）把“执行”异步化。别看Linux/Unix是用来作服务器的，这点上比Windows落后了好多，IOCP（Windows上的AIO，效率极高）在Win2000上就有了。因此学linux的别老以为Windows这里很差那里很差（Windows的多线程机制也因为linux）。

3.1.4 I/O的五种模型

根据以上分析，I/O可分为五种模型：

• 阻塞I/O：全部过程全阻塞
• 非阻塞I/O：若是没有数据buffer，则当即返回EWOULDBLOCK
• I/O复用（select和poll）：在wait和copy阶段分别阻塞
• 信号驱动I/O（SIGIO）：在wait阶段不阻塞，但copy阶段阻塞（信号驱动I/O，即通知）
• 异步I/O（aio）：彻底五阻塞方式，当I/O完成是提供信号

Linux上的前四种I/O模型的“执行”阶段都是同步的，只有最后一种才作到了真正的全异步。第一种阻塞式是最原始的方法，也是最累的办法。固然累与不累要看针对谁。应用程序是和内核打交道的。对应用程序来讲，这种方式是最累的，但对内核来讲这种方式偏偏是最省事的。还拿点菜这事为例，你就是应用程序，厨师就是内核，若是你去了一直等着，厨师就省事了（不用同时处理其余服务员的菜）。固然如今计算机的设计，包括操做系统，愈来愈为终端用户考虑了，为了让用户满意，内核慢慢的承担起愈来愈多的工做，IO模型的演化也是如此。

非阻塞I/O ，I/O复用，信号驱动式I/O其实都是非阻塞的，固然是针对“请求”这个阶段。非阻塞式是主动查询外设状态。I/O复用里的select，poll也是主动查询，不一样的是select和poll能够同时查询多个fd（文件句柄）的状态，另外select有fd个数的限制。epoll是基于回调函数的。信号驱动式I/O则是基于信号消息的。这两个应该能够归到“被动接收消息”那一类中。最后就是伟大的AIO的出现，内核把什么事都干了，对上层应用实现了全异步，性能最好，固然复杂度也最高。

3.2 各I/O模型详细介绍【本部分摘自独孤成博客】：

3.2.1 阻塞I/O

说明：应用程序调用一个IO函数，致使应用程序阻塞，等待数据准备好。 若是数据没有准备好，一直等待数据准备好了，从内核拷贝到用户空间,IO函数返回成功指示。这个不用多解释吧，阻塞套接字。下图是它调用过程的图示：（注，通常网络I/O都是阻塞I/O，客户端发出请求，Web服务器进程响应，在进程没有返回页面以前，这个请求会处于一直等待状态）

3.2.2 非阻塞I/O

咱们把一个套接口设置为非阻塞就是告诉内核，当所请求的I/O操做没法完成时，不要将进程睡眠，而是返回一个错误。这样咱们的I/O操做函数将不断的测试数据是否已经准备好，若是没有准备好，继续测试，直到数据准备好为止。在这个不断测试的过程当中，会大量的占用CPU的时间，全部通常Web服务器都不使用这种I/O模型。具体过程以下图:

3.2.3 I/O复用（select和poll）

I/O复用模型会用到select或poll函数或epoll函数(Linux2.6之后的内核开始支持)，这两个函数也会使进程阻塞，可是和阻塞I/O所不一样的的，这两个函数能够同时阻塞多个I/O操做。并且能够同时对多个读操做，多个写操做的I/O函数进行检测，直到有数据可读或可写时，才真正调用I/O操做函数。具体过程以下图:

3.2.4 信号驱动I/O（SIGIO）

首先，咱们容许套接口进行信号驱动I/O，并安装一个信号处理函数，进程继续运行并不阻塞。当数据准备好时，进程会收到一个SIGIO信号，能够在信号处理函数中调用I/O操做函数处理数据。具体过程以下图:

3.2.5 异步I/O（aio）

当一个异步过程调用发出后，调用者不能马上获得结果。实际处理这个调用的部件在完成后，经过状态、通知和回调来通知调用者的输入输出操做。具体过程以下图:

3.2.6 I/O 模型总结（以下图）

从上图中咱们能够看出，能够看出，越日后，阻塞越少，理论上效率也是最优。其五种I/O模型中，前三种属于同步I/O，后二者属于异步I/O。

同步I/O:

阻塞I/O
非阻塞I/O
I/O复用（select和poll）

异步I/O:

信号驱动I/O（SIGIO） （半异步）
异步I/O（aio） （真正的异步）

异步 I/O 和 信号驱动I/O的区别:

信号驱动 I/O 模式下，内核能够复制的时候通知给咱们的应用程序发送SIGIO 消息。
异步 I/O 模式下，内核在全部的操做都已经被内核操做结束以后才会通知咱们的应用程序。

3.3 Linux I/O模型的具体实现[转自孤城博客]

3.3.1 主要实现方式有如下几种：

• select
• poll
• epoll
• kqueue
• /dev/poll
• iocp

注，其中iocp是Windows实现的，select、poll、epoll是Linux实现的，kqueue是FreeBSD实现的，/dev/poll是SUN的Solaris实现的。select、poll对应第3种（I/O复用）模型，iocp对应第5种（异步I/O）模型，那么epoll、kqueue、/dev/poll呢？其实也同select属于同一种模型，只是更高级一些，能够看做有了第4种（信号驱动I/O）模型的某些特性，如callback机制。

3.3.2 为何epoll、kqueue、/dev/poll比select高级？

答案是，他们无轮询。由于他们用callback取代了。想一想看，当套接字比较多的时候，每次select()都要经过遍历FD_SETSIZE个Socket来完成调度，无论哪一个Socket是活跃的，都遍历一遍。这会浪费不少CPU时间。若是能给套接字注册某个回调函数，当他们活跃时，自动完成相关操做，那就避免了轮询，这正是epoll、kqueue、/dev/poll作的。这样子说可能很差理解，那么我说一个现实中的例子，假设你在大学读书，住的宿舍楼有不少间房间，你的朋友要来找你。select版宿管大妈就会带着你的朋友挨个房间去找，直到找到你为止。而epoll版宿管大妈会先记下每位同窗的房间号，你的朋友来时，只需告诉你的朋友你住在哪一个房间便可，不用亲自带着你的朋友满大楼找人。若是来了10000我的，都要找本身住这栋楼的同窗时，select版和epoll版宿管大妈，谁的效率更高，不言自明。同理，在高并发服务器中，轮询I/O是最耗时间的操做之一，select、epoll、/dev/poll的性能谁的性能更高，一样十分明了。

3.3.3 Windows or *nix （IOCP or kqueue、epoll、/dev/poll）？

诚然，Windows的IOCP很是出色，目前不多有支持asynchronous I/O的系统，可是因为其系统自己的局限性，大型服务器仍是在UNIX下。并且正如上面所述，kqueue、epoll、/dev/poll 与 IOCP相比，就是多了一层从内核copy数据到应用层的阻塞，从而不能算做asynchronous I/O类。可是，这层小小的阻塞无足轻重，kqueue、epoll、/dev/poll 已经作得很优秀了。

3.3.4 总结一些重点

只有IOCP(windows实现)是asynchronous I/O，其余机制或多或少都会有一点阻塞。

select（Linux实现）低效是由于每次它都须要轮询。但低效也是相对的，视状况而定，也可经过良好的设计改善

epoll(Linux实现)、kqueue（FreeBSD实现）、/dev/poll（Solaris实现）是Reacor模式，IOCP是Proactor模式。

Apache 2.2.9以前只支持select模型，2.2.9以后支持epoll模型

Nginx 支持epoll模型

Java nio包是select模型

4、Apache Httpd的工做模式

4.1 apache三种工做模式

咱们都知道Apache有三种工做模块，分别为prefork、worker、event。

• prefork：多进程，每一个请求用一个进程响应，这个过程会用到select机制来通知。
• worker：多线程，一个进程能够生成多个线程，每一个线程响应一个请求，但通知机制仍是select不过能够接受更多的请求。
• event：基于异步I/O模型，一个进程或线程，每一个进程或线程响应多个用户请求，它是基于事件驱动（也就是epoll机制）实现的。

4.2 prefork的工做原理

若是不用“--with-mpm”显式指定某种MPM,prefork就是Unix平台上缺省的MPM.它所采用的预派生子进程方式也是 Apache1.3中采用的模式。prefork自己并无使用到线程，2.0版使用它是为了与1.3版保持兼容性；另外一方面，prefork用单独的子进程来处理不一样的请求，进程之间是彼此独立的,这也使其成为最稳定的MPM之一。

4.3 worker的工做原理

相对于prefork，worker是2.0版中全新的支持多线程和多进程混合模型的MPM。因为使用线程来处理，因此能够处理相对海量的请求，而系统资源的开销要小于基于进程的服务器。可是，worker也使用了多进程,每一个进程又生成多个线程，以得到基于进程服务器的稳定性，这种MPM的工做方 式将是Apache2.0的发展趋势。

4.4 event 基于事件机制的特性

一个进程响应多个用户请求，利用callback机制，让套接字复用，请求过来后进程并不处理请求，而是直接交由其余机制来处理，经过epoll机制来通知请求是否完成；在这个过程当中，进程自己一直处于空闲状态，能够一直接收用户请求。能够实现一个进程程响应多个用户请求。支持持海量并发链接数，消耗更少的资源。

5、如何提升Web服务器的并发链接处理能力

有几个基本条件：

• 基于线程，即一个进程生成多个线程，每一个线程响应用户的每一个请求。
• 基于事件的模型，一个进程处理多个请求，而且经过epoll机制来通知用户请求完成。
• 基于磁盘的AIO（异步I/O）
• 支持mmap内存映射，mmap传统的web服务器，进行页面输入时，都是将磁盘的页面先输入到内核缓存中，再由内核缓存中复制一份到web服务器上，mmap机制就是让内核缓存与磁盘进行映射，web服务器，直接复制页面内容便可。不须要先把磁盘的上的页面先输入到内核缓存去。

恰好，Nginx 支持以上全部特性。因此Nginx官网上说，Nginx支持50000并发，是有依据的。

6、Nginx优异之处

6.1 简介

传统上基于进程或线程模型架构的web服务经过每进程或每线程处理并发链接请求，这势必会在网络和I/O操做时产生阻塞，其另外一个必然结果则是对内存或CPU的利用率低下。生成一个新的进程/线程须要事先备好其运行时环境，这包括为其分配堆内存和栈内存，以及为其建立新的执行上下文等。这些操做都须要占用CPU，并且过多的进程/线程还会带来线程抖动或频繁的上下文切换，系统性能也会由此进一步降低。另外一种高性能web服务器/web服务器反向代理：Nginx（Engine X），nginx的主要着眼点就是其高性能以及对物理计算资源的高密度利用，所以其采用了不一样的架构模型。受启发于多种操做系统设计中基于“事件”的高级处理机制，nginx采用了模块化、事件驱动、异步、单线程及非阻塞的架构，并大量采用了多路复用及事件通知机制。在nginx中，链接请求由为数很少的几个仅包含一个线程的进程worker以高效的回环(run-loop)机制进行处理，而每一个worker能够并行处理数千个的并发链接及请求。

6.2 Nginx 工做原理

Nginx会按需同时运行多个进程：一个主进程(master)和几个工做进程(worker)，配置了缓存时还会有缓存加载器进程(cache loader)和缓存管理器进程(cache manager)等。全部进程均是仅含有一个线程，并主要经过“共享内存”的机制实现进程间通讯。主进程以root用户身份运行，而worker、cache loader和cache manager均应以非特权用户身份运行。

主进程主要完成以下工做：

• 读取并验正配置信息；
• 建立、绑定及关闭套接字；
• 启动、终止及维护worker进程的个数；
• 无须停止服务而从新配置工做特性；
• 控制非中断式程序升级，启用新的二进制程序并在须要时回滚至老版本；
• 从新打开日志文件；
• 编译嵌入式perl脚本；
• worker进程主要完成的任务包括：
• 接收、传入并处理来自客户端的链接；
• 提供反向代理及过滤功能；
• nginx任何能完成的其它任务；

注：若是负载以CPU密集型应用为主，如SSL或压缩应用，则worker数应与CPU数相同；若是负载以IO密集型为主，如响应大量内容给客户端，则worker数应该为CPU个数的1.5或2倍。

6.3 Nginx 架构

Nginx的代码是由一个核心和一系列的模块组成, 核心主要用于提供Web Server的基本功能，以及Web和Mail反向代理的功能；还用于启用网络协议，建立必要的运行时环境以及确保不一样的模块之间平滑地进行交互。不过，大多跟协议相关的功能和某应用特有的功能都是由nginx的模块实现的。这些功能模块大体能够分为事件模块、阶段性处理器、输出过滤器、变量处理器、协议、upstream和负载均衡几个类别，这些共同组成了nginx的http功能。事件模块主要用于提供OS独立的(不一样操做系统的事件机制有所不一样)事件通知机制如kqueue或epoll等。协议模块则负责实现nginx经过http、tls/ssl、smtp、pop3以及imap与对应的客户端创建会话。在Nginx内部，进程间的通讯是经过模块的pipeline或chain实现的；换句话说，每个功能或操做都由一个模块来实现。例如，压缩、经过FastCGI或uwsgi协议与upstream服务器通讯，以及与memcached创建会话等。

6.4 Nginx 基础功能

• 处理静态文件，索引文件以及自动索引；
• 反向代理加速(无缓存)，简单的负载均衡和容错；
• FastCGI，简单的负载均衡和容错；
• 模块化的结构。过滤器包括gzipping, byte ranges, chunked responses, 以及 SSI-filter 。在SSI过滤器中，到同一个 proxy 或者 FastCGI 的多个子请求并发处理；
• SSL 和 TLS SNI 支持；

6.5 Nginx IMAP/POP3 代理服务功能

• 使用外部 HTTP 认证服务器重定向用户到 IMAP/POP3 后端；
• 使用外部 HTTP 认证服务器认证用户后链接重定向到内部的 SMTP 后端；
• 认证方法：
• POP3: POP3 USER/PASS, APOP, AUTH LOGIN PLAIN CRAM-MD5;
• IMAP: IMAP LOGIN;
• SMTP: AUTH LOGIN PLAIN CRAM-MD5;
• SSL 支持；
• 在 IMAP 和 POP3 模式下的 STARTTLS 和 STLS 支持；

6.6 Nginx 支持的操做系统

• FreeBSD 3.x, 4.x, 5.x, 6.x i386; FreeBSD 5.x, 6.x amd64;
• Linux 2.2, 2.4, 2.6 i386; Linux 2.6 amd64;
• Solaris 8 i386; Solaris 9 i386 and sun4u; Solaris 10 i386;
• MacOS X (10.4) PPC;
• Windows 编译版本支持 windows 系列操做系统;

6.7 Nginx 结构与扩展

• 一个主进程和多个工做进程，工做进程运行于非特权用户；
• kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), select, 以及 poll 支持；
• kqueue支持的不一样功能包括 EV_CLEAR, EV_DISABLE （临时禁止事件）， NOTE_LOWAT, EV_EOF, 有效数据的数目，错误代码；
• sendfile (FreeBSD 3.1+), sendfile (Linux 2.2+), sendfile64 (Linux 2.4.21+), 和 sendfilev (Solaris 8 7/01+) 支持；
• 输入过滤 (FreeBSD 4.1+) 以及 TCP_DEFER_ACCEPT (Linux 2.4+) 支持；
• 10,000 非活动的 HTTP keep-alive 链接仅须要 2.5M 内存。
• 最小化的数据拷贝操做；

6.8 Nginx 其余HTTP功能

• 基于IP 和名称的虚拟主机服务；
• Memcached 的 GET 接口；
• 支持 keep-alive 和管道链接；
• 灵活简单的配置；
• 从新配置和在线升级而无须中断客户的工做进程；
• 可定制的访问日志，日志写入缓存，以及快捷的日志回卷；
• 4xx-5xx 错误代码重定向；
• 基于 PCRE 的 rewrite 重写模块；
• 基于客户端 IP 地址和 HTTP 基本认证的访问控制；
• PUT, DELETE, 和 MKCOL 方法；
• 支持 FLV （Flash 视频）；
• 带宽限制；

6.9 为何选择Nginx

• 在高链接并发的状况下，Nginx是Apache服务器不错的替代品: Nginx在美国是作虚拟主机生意的老板们常常选择的软件平台之一. 可以支持高达 50,000 个并发链接数的响应, 感谢Nginx为咱们选择了 epoll and kqueue 做为开发模型。
• Nginx做为负载均衡服务器: Nginx 既能够在内部直接支持 Rails 和 PHP 程序对外进行服务, 也能够支持做为 HTTP代理 服务器对外进行服务. Nginx采用C进行编写, 不管是系统资源开销仍是CPU使用效率都比 Perlbal 要好不少。
• 做为邮件代理服务器: Nginx 同时也是一个很是优秀的邮件代理服务器（最先开发这个产品的目的之一也是做为邮件代理服务器）, Last.fm 描述了成功而且美妙的使用经验.
• Nginx 是一个 [#installation 安装] 很是的简单 , 配置文件 很是简洁（还可以支持perl语法）,Bugs 很是少的服务器: Nginx 启动特别容易, 而且几乎能够作到7*24不间断运行，即便运行数个月也不须要从新启动. 你还可以 不间断服务的状况下进行软件版本的升级 。
• Nginx 的诞生主要解决C10K问题