为什么nginx性能优于Apache性能？

作者：linux

Nginx 在几年内征服了大多数 Web 服务器。众所周知，Nginx 在处理大并发静态请求方面明显比 Httpd 高效，甚至可以轻松解决 C10K 问题。

对于大量并发连接，Nginx 是 Apache 的一个很好的替代方案。 Nginx 还可以用作第 7 层负载均衡器，根据我的测试结果，Nginx + PHP（FastCGI）可以处理超过 30,000 个并发连接，相当于相同环境下 Apache 的 10 倍。

一般来说，4GB内存的服务器+Apache（prefork模式）一般只能处理3000个并发连接，因为它们占用了3GB以上的内存，必须为系统预留1GB的内存。我曾经有两台 Apache 服务器。由于配置文件中设置的MaxClients为4000，当Apache并发连接数达到3800时，服务器的内存和缓存就满了，崩溃了。

而这个 Nginx + PHP (FastCGI) 服务器有 30,000 个并发连接。 10个打开的Nginx进程消耗150M内存（15M*10=150M），打开64个php-cgi。该进程消耗1280M内存（20M*64=1280M），加上系统本身消耗的内存，总共消耗不到2GB内存。如果服务器内存较小，只能开启25个php-cgi进程，所以php-cgi消耗的总内存只有5亿。

在3万并发连接下，PHP程序访问Nginx+PHP（FastCGI）服务器的速度还是很快的。

为什么 Nginx 在处理高并发方面比 httpd 更好？我们先来了解一下这两种Web服务器的工作原理和工作模式。

1. Apache 的三种工作模式

我们都知道Apache 有三个工作模块：prefork、worker 和 event。

• prefork：多进程，一个进程响应每个请求。此过程将使用选择加入机制进行通知。
• worker：多线程，一个进程可以产生多个线程，每个线程响应一个请求，但是通知机制仍然是选择性的，但是可以接受多个请求。
• 事件：基于异步I/O模型、进程或线程，每个进程或线程响应多个用户请求，基于事件（即epoll机制）实现。

1。 prefork 的工作原理

如果您没有使用“-with-mpm”明确指定特定的 MPM，则 prefork 是 Unix 平台上的默认 MPM。它采用的预分叉子进程的方式也是Apache1.3中采用的模式。

预成型件本身不使用螺纹。 2.0版本使用它来保持与1.3版本的兼容性；另一方面，预分叉使用单独的线程来处理不同的请求，并且进程彼此独立。这也使其成为最稳定的 MPM 之一。

2。 Worker

Worker 的工作原理 Worker 是 2.0 版本相比 prefork 新增的 MPM，支持多线程、多进程混合模型。由于使用线程进行处理，因此可以处理相对大量的请求，并且系统资源的开销比基于进程的服务器要少。

但是，worker 也使用多个进程，每个进程生成多个线程，以获得基于进程的服务器的稳定性。这种MPM工作方式将是Apache2.0的发展趋势。

3。基于事件机制功能的事件

一个进程使用回调机制响应多个用户请求，以重用套接字。当请求到达时，进程并不处理该请求，而是直接将其传递给其他机制。处理，通过epoll机制通知请求是否完成；在此过程中，进程本身处于空闲状态，并且始终可以接受用户请求。可以实现响应多个用户的请求的流程。支持大量并发连接，消耗资源少。

2。如何提高Web服务器并发连接处理能力

有几个基本条件：

1。基于线程，意味着一个进程产生多个线程，每个线程响应每个用户请求。

2。基于事件的模型，单个进程处理多个请求，并通过epoll机制通知用户请求完成。

3。磁盘 AIO（异步 I/O）

4。支持mmap内存映射。传统的 mmap Web 服务器插入页面时，首先将磁盘页面插入内核缓存，然后从内核缓存复制一份副本到 Web 服务器。 mmap机制允许将内核缓存映射到磁盘。 Web服务器可以直接复制页面内容。无需先缓存磁盘页面。

Nginx 恰好支持以上所有功能。所以Nginx官网说Nginx支持5万并发，也是有道理的。

3。 Nginx 的优点

基于进程或线程模型架构的 Web 服务传统上按进程或按线程处理并发连接请求，这不可避免地会导致网络和 I/O 操作期间的阻塞。此外，不可避免的结果是内存或CPU使用率较低。

生成一个新的进程/线程需要提前准备其运行环境，包括分配堆内存和栈内存以及为其创建新的执行上下文。这些操作需要占用CPU，过多的进程/线程也会导致线程抖动或者频繁的上下文切换，进一步降低系统性能。

另一种高性能 Web 服务器/反向代理 Web 服务器：Nginx。 Nginx的主要关注点是其高性能和对物理计算资源的高密度使用，因此它采用了不同的架构模型。受到各种操作系统设计中先进的基于“事件”的处理机制的启发，Nginx采用了模块化、事件驱动、异步、单线程、非阻塞的架构，并使用了大量的复用和事件通知机制。

在 Nginx 中，连接请求由多个仅包含一个线程的进程 Worker 处理，具有高效的运行循环机制，每个 Worker 可以处理数千个并发连接和并行连接。问。

4。 Nginx 的工作原理

Nginx 会根据需要同时运行多个进程：主进程（master）和若干工作进程（worker）。配置缓存时，也会发生缓存加载过程。 ）和缓存管理器进程（cache manager）等。所有进程都只包含一个线程，进程间通信主要通过“共享内存”机制实现。主进程以 root 身份运行，而工作进程、缓存加载器和缓存管理器应以非特权用户身份运行。

在高连接并发的情况下，Nginx 是 Apache 服务器的一个很好的替代方案。

Nginx 安装非常简单，配置文件非常简洁（还可以支持 Pearl 语法）并且错误很少。服务器：Nginx非常容易启动，即使运行几个月也能几乎7*24不间断地运行。无需重新启动。您还可以在不中断服务的情况下更新软件版本。

5。 Nginx的诞生主要是解决C10K的问题

最后我们从大家都使用的复用IO模型来分析：

1。选择型号：（使用Apache，由于模块限制等，使用不多）；

单个进程可以监控的文件描述符数量有最大限制；

select()维护的一个数据结构，用于存储大量文件描述符，随着文件描述符数量的增加，其复制用户态和内核地址空间带来的开销线性增加；

由于网络响应时间延迟，大量 TCP 连接处于空闲状态，但 select() 调用仍会对所有套接字执行线性操作。扫描会产生一些开销；

2。 poll：poll 是 Unix 使用 select 重新实现的。唯一解决的问题是poll对文件描述符的最大数量没有限制；

3。 epoll模型：（使用Nginx）

epoll带来了两个大大提高性能的优点：

1）基于事件的就绪通知方法，select/poll方法，进程只有调用某个方法后才会响应内核。所有监控的文件描述符都会被扫描，epoll事件通过epoll_ctl()注册文件描述符。当文件描述符准备好后，内核会使用类似callback的回调机制来快速激活文件描述符，epoll_wait()会收到通知

2）当调用一次epoll_wait()来获取准备好的文件描述符时，会发生什么返回的不是实际的描述符，而是表示准备好的描述符数量的值。获取这些值并导航到epoll指定的文件。只需按顺序获取数组中对应数量的文件描述符即可。这里使用了内存映射技术（mmap）来避免复制大量文件描述符带来的开销

3）当然，epoll也有一些局限性。 epoll仅适用于Linux2.6，其他平台不可用。这当然与像 Apache 这样优秀的跨平台服务器是不一致的。

4）简单来说，epoll 是轮询的改进版本。单个进程管理的文件描述符没有最大限制。但epoll只能在Linux平台上使用。 Apache 不作为多平台使用。