Nginx、Apache工做原理以及nginx为什么比Apache高效

Nginx才短短几年，就拿下了web服务器大笔江山，众所周知，Nginx在处理大并发静态请求方面，效率明显高于httpd，甚至能轻松解决C10K问题。

在高并发链接的状况下，Nginx是Apache服务器不错的替代品。Nginx同时也能够做为7层负载均衡服务器来使用。根据个人测试结果，Nginx 0.7.14 + PHP 5.2.6 (FastCGI) 能够承受3万以上的并发链接数，至关于同等环境下Apache的10倍。

通常来讲，4GB内存的服务器+Apache（prefork模式）通常只能处理3000个并发链接，由于它们将占用3GB以上的内存，还得为系统预留1GB的内存。我曾经就有两台Apache服务器，由于在配置文件中设置的MaxClients为4000，当Apache并发链接数达到3800时，致使服务器内存和Swap空间用满而崩溃。

而这台 Nginx 0.7.14 + PHP 5.2.6 (FastCGI) 服务器在3万并发链接下，开启的10个Nginx进程消耗150M内存（15M*10=150M），开启的64个php-cgi进程消耗1280M内存（20M*64=1280M），加上系统自身消耗的内存，总共消耗不到2GB内存。若是服务器内存较小，彻底能够只开启25个php-cgi进程，这样php-cgi消耗的总内存数才500M。

在3万并发链接下，访问Nginx 0.7.14 + PHP 5.2.6 (FastCGI) 服务器的PHP程序，仍然速度飞快。

为何Nginx在处理高并发方面要优于httpd，咱们先从两种web服务器的工做原理以及工做模式提及。

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机制来通知请求是否完成；在这个过程当中，进程自己一直处于空闲状态，能够一直接收用户请求。能够实现一个进程程响应多个用户请求。支持持海量并发链接数，消耗更少的资源。

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

有几个基本条件：

 1.基于线程，即一个进程生成多个线程，每一个线程响应用户的每一个请求。

 2.基于事件的模型，一个进程处理多个请求，而且经过epoll机制来通知用户请求完成。

 3.基于磁盘的AIO（异步I/O）

 4.支持mmap内存映射，mmap传统的web服务器，进行页面输入时，都是将磁盘的页面先输入到内核缓存中，再由内核缓存中复制一份到web服务器上，mmap机制就是让内核缓存与磁盘进行映射，web服务器，直接复制页面内容便可。不须要先把磁盘的上的页面先输入到内核缓存去。

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

Nginx优异之处

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

Nginx 工做原理

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

在高链接并发的状况下，Nginx是Apache服务器不错的替代品

 Nginx 安装很是的简单 , 配置文件很是简洁（还可以支持perl语法）,Bugs 很是少的服务器: Nginx 启动特别容易, 而且几乎能够作到7*24不间断运行，即便运行数个月也不须要从新启动. 你还可以 不间断服务的状况下进行软件版本的升级 。

 Nginx 的诞生主要解决C10K问题

最后咱们从各自使用的多路复用IO模型来分析：
  
select模型：（apache使用，因为受模块等限制，用的很少）
  

单个进程可以 监视的文件描述符的数量存在最大限制

select()所维护的 存储大量文件描述符的数据结构 ，随着文件描述符数量的增加，其在用户态和内核的地址空间的复制所引起的开销也会线性增加

因为网络响应时间的延迟使得大量TCP链接处于非活跃状态，但调用select()仍是会对 全部的socket进行一次线性扫描 ，会形成必定的开销

poll：poll是unix沿用select本身从新实现了一遍，惟一解决的问题是poll 没有最大文件描述符数量的限制

epoll模型：（nginx使用）

epoll带来了两个优点，大幅度提高了性能：

基于事件的就绪通知方式 ，select/poll方式，进程只有在调用必定的方法后，内核才会对全部监视的文件描述符进行扫描，而epoll事件经过epoll_ctl()注册一个文件描述符，一旦某个文件描述符就绪时，内核会采用相似call back的回调机制，迅速激活这个文件描述符，epoll_wait()便会获得通知

调用一次epoll_wait()得到就绪文件描述符时，返回的并非实际的描述符，而是一个表明就绪描述符数量的值，拿到这些值去epoll指定的一个数组中依次取得相应数量的文件描述符便可，这里使用内存映射（mmap）技术， 避免了复制大量文件描述符带来的开销

固然epoll也有必定的局限性， epoll只有Linux2.6才有实现 ，而其余平台都没有，这和apache这种优秀的跨平台服务器，显然是有些背道而驰了。简单来讲epoll是select的升级版，单进程管理的文件描述符没有最大限制。但epoll只有linux平台可以使用。做为跨平台的Apache没有使用。