Nginx与Apache：Web服务器性能大比拼

在构建网站时，选择合适的Web服务器是至关重要的。Nginx和Apache是两个最受欢迎的开源Web服务器解决方案，它们各自拥有独特的特性与优势。本文将对Nginx和Apache进行比较，帮助你了解哪个更适合你的项目。

Web 服务介绍

Netcraft公司于1994年底在英国成立，多年来一直致力于互联网市场以及在线安全方面的咨询服务，其中在国际上最具影响力的当属其针对网站服务器，域名解析/主机提供商，以及SSL市场所做的客观严谨的分析研究。

Apache 经典的 Web 服务端

Apache起初由美国的伊利诺伊大学香槟分校的国家超级计算机应用中心开发，目前经历了两大版本分别是1.X和2.X，其可以通过编译安装实现特定的功能。

官方网站：http://www.apache.org

Apache HTTP服务器最初是基于阻塞式 I/O 模型实现的。在阻塞式 I/O 模型中，每个连接都需要一个单独的线程来处理它的 I/O 操作。因此，如果有大量的并发连接，服务器将会创建大量的线程，这会导致服务器性能下降。

为了解决这个问题，Apache 2.0 引入了基于事件驱动的架构，以提高服务器的性能和可伸缩性。在基于事件驱动的架构中，服务器使用一组事件处理程序来处理多个连接。这些事件处理程序使用基于 select 或 epoll 的多路复用技术来处理多个连接。这使得服务器可以使用更少的线程来处理大量的连接，从而提高了服务器的性能和可伸缩性。

因此，Apache HTTP服务器在 2.0 版本及以后的版本中使用基于事件驱动的架构，并使用基于 select 或 epoll 的多路复用技术来处理多个连接。

Apache的MPM（Multi-Processing Module）是Apache服务器用来管理进程或线程的模块，它决定了

Apache服务器的工作方式，包括如何处理并发连接、如何分配资源等。

MPM multi-processing module 有三种工作模式

Apache prefork 模型

预派生模式，有一个主控制进程，然后生成多个子进程，每个子进程有一个独立的线程响应用户请求，相对比较占用内存，但是比较稳定，可以设置最大和最小进程数，是最古老的一种模式，也是最稳定的模式，适用于访问量不是很大的场景。

优点：稳定

缺点：每个用户请求需要对应开启一个进，占用资源较多，并发性差，不适用于高并发场景
Apache worker 模型

一种多进程和多线程混合的模型，有一个控制进程，启动多个子进程，每个子进程里面包含固定的线

程，使用线程程来处理请求，当线程不够使用的时候会再启动一个新的子进程，然后在进程里面再启动线程处理请求，由于其使用了线程处理请求，因此可以承受更高的并发。

优点：相比prefork 占用的内存较少，可以同时处理更多的请求,可以基于select的IO多路复用技术实现

使用更少的线程支持更多的并发连接。

缺点：使用keepalive的长连接方式，某个线程会一直被占据，即使没有传输数据，也需要一直等待到超时才会被释放。如果过多的线程，被这样占据，也会导致在高并发场景下的无服务线程可用。（该问题在prefork模式下，同样会发生）
Apache event 模型

Apache中最新的模式，2012年发布的apache 2.4.X系列正式支持event 模型，属于事件驱动模型

(epoll)，每个进程响应多个请求，在现在版本里的已经是稳定可用的模式。它和worker模式很像，最大的区别在于，它解决了keepalive场景下，长期被占用的线程的资源浪费问题（某些线程因为被

keepalive，空挂在哪里等待，中间几乎没有请求过来，甚至等到超时）。event MPM中，会有一个专

门的线程来管理这些keepalive类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放。这样增强了高并发场景下的请求处理能力。

优点：单线程响应多请求，占据更少的内存，高并发下表现更优秀，会有一个专门的线程来管理keep

alive类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放,可以基于epoll 更加高效的IO多路复用技术实现使用更少的线程支持更多的并发连接。

缺点：没有线程安全控制

Nginx 高性能的 Web 服务端

Nginx是由俄罗斯国立莫斯科鲍曼科技大学在1994年毕业的学生为俄罗斯rambler.ru公司开发的，开发

工作最早从2002年开始，第一次公开发布时间是2004年10月4日，版本号是0.1.0

2019年3月11日F5 与 NGINX达成协议,F5 将收购 NGINX 的所有已发行股票，总价值约为 6.7 亿美元。6.7亿美金约合44.97亿人民币,nginx核心模块代码长度198430（包括空格、注释），所以一行代码约为2.2万人民币

官网地址：http://www.nginx.org/

Nginx历经十几年的迭代更新（https://nginx.org/en/CHANGES）， 目前功能已经非常完善且运行稳

定，分为社区版本和商业版，另外Nginx的社区版本分为开发版（奇数）、最新稳定版（偶数）和过期版，nginx以功能丰富著称，它即可以作为http服务器，也可以作为反向代理服务器或者邮件服务器，能够快速的响应静态网页的请求，支持FastCGI/SSL/Virtual Host/URL Rwrite/Gzip/HTTP Basic Auth/http或者TCP的负载均衡(1.9版本以上且开启stream模块)等功能，并且支持第三方的功能扩展。

天猫 淘宝 京东 小米 163 新浪等一线互联网公司都在用Nginx或者进行二次开发

用户访问体验和性能

用户访问体验统计

互联网存在用户速度体验的1-3-10原则，即1秒最优，1-3秒较优，3~10秒比较慢，10秒以上用户无法接受。用户放弃一个产品的代价很低，只是换一个URL而已。

全球最大搜索引擎 Google：慢500ms = 20% 将放弃访问。

全球最大的电商零售网站亚马逊：慢100ms = 1% 将放弃交易

有很多研究都表明，性能对用户的行为有很大的影响：

79%的用户表示不太可能再次打开一个缓慢的网站

47%的用户期望网页能在2秒钟以内加载

40%的用户表示如果加载时间超过三秒钟，就会放弃这个网站

页面加载时间延迟一秒可能导致转换损失7%，页面浏览量减少11%

8秒定律：用户访问一个网站时，如果等待网页打开的时间超过8秒，会有超过30%的用户放弃等待请珍惜每一毫秒的时间 !
影响用户体验的因素

据说马云在刚开始创业在给客户演示时，打开一个网站花了不到四个小时。

https://www.toutiao.com/article/6440287421317218562/?wid=1669189116646
https://www.shuimiao.net/NjHaO/

影响用户体验的因素

#客户端
客户端硬件配置
客户端网络速率 
客户端与服务端距离
#服务器
服务端网络速率
服务端硬件配置
服务端架构设计
服务端应用程序工作模式
服务端并发数量
服务端响应文件大小及数量 buffer cache
服务端I/O压力

服务端 I/O 流程

I/O在计算机中指Input/Output， IOPS (Input/Output Per Second)即每秒的输入输出量(或读写次数)，

是衡量磁盘性能的主要指标之一。IOPS是指单位时间内系统能处理的I/O请求数量，一般以每秒处理的I/O请求数量为单位，I/O请求通常为读或写数据操作请求。

一次完整的I/O是用户空间的进程数据与内核空间的内核数据的报文的完整交换，但是由于内核空间与用户空间是严格隔离的，所以其数据交换过程中不能由用户空间的进程直接调用内核空间的内存数据，而是需要经历一次从内核空间中的内存数据copy到用户空间的进程内存当中，所以简单说I/O就是把数据从内核空间中的内存数据复制到用户空间中进程的内存当中。

Linux 的 I/O

• 磁盘I/O
• 网络I/O : 一切皆文件，本质为对socket文件的读写

磁盘 I/O

磁盘I/O是进程向内核发起系统调用，请求磁盘上的某个资源比如是html 文件或者图片，然后内核通过

相应的驱动程序将目标文件加载到内核的内存空间，加载完成之后把数据从内核内存再复制给进程内

存，如果是比较大的数据也需要等待时间
网络 I/O

网络通信就是网络协议栈到用户空间进程的IO就是网络IO

网络I/O 处理过程

获取请求数据，客户端与服务器建立连接发出请求，服务器接受请求（1-3）
构建响应，当服务器接收完请求，并在用户空间处理客户端的请求，直到构建响应完成（4）
返回数据，服务器将已构建好的响应再通过内核空间的网络 I/O 发还给客户端（5-7）

不论磁盘和网络I/O

每次I/O，都要经由两个阶段：
第一步：将数据从文件先加载至内核内存空间（缓冲区），等待数据准备完成，时间较长
第二步：将数据从内核缓冲区复制到用户空间的进程的内存中，时间较短

I/O 模型

I/O 模型相关概念

同步和异步

关注的是消息通信机制，即调用者在等待一件事情的处理结果时，被调用者是否提供完成状态的通知。

• 同步：synchronous，被调用者并不提供事件的处理结果相关的通知消息，需要调用者主动询问事
  情是否处理完成
• 异步：asynchronous，被调用者通过状态、通知或回调机制主动通知调用者被调用者的运行状态

阻塞和非阻塞

关注调用者在等待结果返回之前所处的状态

• 阻塞：blocking，指IO操作需要彻底完成后才返回到用户空间，调用结果返回之前，调用者被挂
  起，干不了别的事情。
• 非阻塞：nonblocking，指IO操作被调用后立即返回给用户一个状态值，而无需等到IO操作彻底完
  成，在最终的调用结果返回之前，调用者不会被挂起，可以去做别的事情。

网络 I/O 模型

阻塞型、非阻塞型、复用型、信号驱动型、异步

参看:《UNIX网络编程 卷1：套接字联网API 》(美)W. Richard Stevens 著
阻塞型 I/O 模型（blocking IO）

阻塞IO模型是最简单的I/O模型，用户线程在内核进行IO操作时被阻塞。

用户线程通过系统调用read发起I/O读操作，由用户空间转到内核空间。内核等到数据包到达后，然后将接收的数据拷贝到用户空间，完成read操作。

用户需要等待read将数据读取到buffer后，才继续处理接收的数据。整个I/O请求的过程中，用户线程是被阻塞的，这导致用户在发起IO请求时，不能做任何事情，对CPU的资源利用率不够。

优点：程序简单，在阻塞等待数据期间进程/线程挂起，基本不会占用 CPU 资源。

缺点：每个连接需要独立的进程/线程单独处理，当并发请求量大时为了维护程序，内存、线程切换开销较大，apache 的prefork使用的是这种模式。

同步阻塞：程序向内核发送I/O请求后一直等待内核响应，如果内核处理请求的IO操作不能立即返回,则进程将
一直等待并不再接受新的请求，并由进程轮询查看I/O是否完成，完成后进程将I/O结果返回给Client，在IO
没有返回期间进程不能接受其他客户的请求，而且是有进程自己去查看I/O是否完成，这种方式简单，但是比
较慢，用的比较少。

非阻塞型 I/O 模型 (nonblocking IO)

用户线程发起IO请求时立即返回。但并未读取到任何数据，用户线程需要不断地发起IO请求，直到数据到达后，才真正读取到数据，继续执行。即 "轮询"机制存在两个问题：如果有大量文件描述符都要等，那么就得一个一个的read。这会带来大量的Context Switch（read是系统调用，每调用一次就得在用户态和核心态切换一次）。轮询的时间不好把握。这里是要猜多久之后数据才能到。等待时间设的太长，程序响应延迟就过大;设的太短，就会造成过于频繁的重试，干耗CPU而已，是比较浪费CPU的方式，一般很少直接使用这种模型，而是在其他IO模型中使用非阻塞IO这一特性。

非阻塞：程序向内核发送请I/O求后一直等待内核响应，如果内核处理请求的IO操作不能立即返回IO结果，进程将不再等待，而且继续处理其他请求，但是仍然需要进程隔一段时间就要查看内核I/O是否完成。

查看上图可知，在设置连接为非阻塞时，当应用进程系统调用recvfrom 没有数据返回时，内核会立即

返回一个EWOULDBLOCK 错误，而不会一直阻塞到数据准备好。如上图在第四次调用时有一个数据报准备好了，所以这时数据会被复制到应用进程缓冲区，于是recvfrom 成功返回数据。

当一个应用进程这样循环调用recvfrom 时，称之为轮询polling 。这么做往往会耗费大量CPU时间，实际使用很少。
I/O 多路复用型 (I/O multiplexing)

网络I/O复用是指利用操作系统提供的一种机制，同时监控多个I/O事件（如可读、可写、异常等），当有I/O事件发生时，通知应用程序进行相应的处理。

通常，一个应用程序需要对多个网络连接进行处理，传统的方法是使用多线程或多进程模型，为每个连接创建一个线程或进程进行处理。这种方法存在一些问题，例如线程或进程的创建和销毁需要消耗大量的系统资源，且容易导致线程或进程的数量过多，进而导致系统崩溃或运行缓慢。

相比于传统的多线程或多进程模型，网络I/O复用模型可以有效地减少线程或进程的数量，从而提高系统的性能和稳定性。通过网络I/O复用模型，应用程序可以通过一个线程或进程同时监控多个网络连接，当有网络I/O事件发生时，操作系统会通知应用程序进行相应的处理，从而实现多个网络连接的并发处理。

上面的模型中,每一个文件描述符对应的IO是由一个线程监控和处理,即如果一个I/O流进来，就开启一个进程处理这个I/O流。那么假设现在有一百万个I/O流进来，那就需要开启一百万个进程一一对应处理这些I/O流（------这就是传统意义下的多进程并发处理）。一百万个进程，CPU占有率会多高，所以提出了I/O多路复用这个模型，一个线程，通过记录I/O流的状态来同时管理多个I/O，可以提高服务器的吞吐能力

多路复用IO指一个线程可以同时（实际是交替实现，即并发完成）监控和处理多个文件描述符对应各自的IO，即复用同一个线程

一个线程之所以能实现同时处理多个IO,是因为这个线程调用了内核中的SELECT,POLL或EPOLL等系统调用，从而实现多路复用IO

I/O multiplexing 主要包括:select，poll，epoll三种系统调用，select/poll/epoll的好处就在于单个

process就可以同时处理多个网络连接的IO。

它的基本原理就是select/poll/epoll这个function会不断的轮询所负责的所有socket，当某个socket有数

据到达了，就通知用户进程。

当用户进程调用了select，那么整个进程会被block，而同时，kernel会"监视"所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。

在Apache中，MPM模块可以使用select或epoll技术来实现并发连接的处理。具体来说，当Apache使用Prefork模型时，它使用阻塞式I/O来处理连接，而在Worker和Event模型中，它们使用select或epoll来实现并发连接的非阻塞I/O处理。

IO多路复用（IO Multiplexing) ：是一种机制，程序注册一组socket文件描述符给操作系统，表示"我要
监视这些fd是否有IO事件发生，有了就告诉程序处理"
 IO多路复用一般和NIO一起使用的。NIO和IO多路复用是相对独立的。NIO仅仅是指IO API总是能立刻返回，
不会被Blocking;而IO多路复用仅仅是操作系统提供的一种便利的通知机制。操作系统并不会强制这俩必须得
一起用，可以只用IO多路复用 + BIO，这时还是当前线程被卡住。IO多路复用和NIO是要配合一起使用才有
实际意义
IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取，就通知该进程
多个连接共用一个等待机制，本模型会阻塞进程，但是进程是阻塞在select或者poll这两个系统调用上，而
不是阻塞在真正的IO操作上
用户首先将需要进行IO操作添加到select中，同时等待select系统调用返回。当数据到达时，IO被激活，
select函数返回。用户线程正式发起read请求，读取数据并继续执行
从流程上来看，使用select函数进行IO请求和同步阻塞模型没有太大的区别，甚至还多了添加监视IO，以及
调用select函数的额外操作，效率更差。并且阻塞了两次，但是第一次阻塞在select上时，select可以监
控多个IO上是否已有IO操作准备就绪，即可达到在同一个线程内同时处理多个IO请求的目的。而不像阻塞IO
那种，一次只能监控一个IO
虽然上述方式允许单线程内处理多个IO请求，但是每个IO请求的过程还是阻塞的（在select函数上阻塞），
平均时间甚至比同步阻塞IO模型还要长。如果用户线程只是注册自己需要的IO请求，然后去做自己的事情，等
到数据到来时再进行处理，则可以提高CPU的利用率
IO多路复用是最常使用的IO模型，但是其异步程度还不够"彻底"，因它使用了会阻塞线程的select系统调
用。因此IO多路复用只能称为异步阻塞IO模型，而非真正的异步IO

优缺点

• 优点：可以基于一个阻塞对象，同时在多个描述符上等待就绪，而不是使用多个线程(每个文件描述符一个线程)，这样可以大大节省系统资源
• 缺点：当连接数较少时效率相比多线程+阻塞 I/O 模型效率较低，可能延迟更大，因为单个连接处
  理需要 2 次系统调用，占用时间会有增加

IO多路复用适用如下场合：

• 当客户端处理多个描述符时（一般是交互式输入和网络套接口），必须使用I/O复用
• 当一个客户端同时处理多个套接字时，此情况可能的但很少出现
• 当一个服务器既要处理监听套接字，又要处理已连接套接字，一般也要用到I/O复用
• 当一个服务器即要处理TCP，又要处理UDP，一般要使用I/O复用
• 当一个服务器要处理多个服务或多个协议，一般要使用I/O复用

信号驱动式 I/O 模型 (signal-driven IO)

信号驱动I/O的意思就是进程现在不用傻等着，也不用去轮询。而是让内核在数据就绪时，发送信号通知进程。

调用的步骤是，通过系统调用sigaction ，并注册一个信号处理的回调函数，该调用会立即返回，然后

主程序可以继续向下执行，当有I/O操作准备就绪,即内核数据就绪时，内核会为该进程产生一个

SIGIO信号，并回调注册的信号回调函数，这样就可以在信号回调函数中系统调用

recvfrom 获取数据,将用户进程所需要的数据从内核空间拷贝到用户空间。

此模型的优势在于等待数据报到达期间进程不被阻塞。用户主程序可以继续执行，只要等待来自信号处理函数的通知。

在信号驱动式 I/O 模型中，应用程序使用套接口进行信号驱动 I/O，并安装一个信号处理函数，进程继

续运行并不阻塞

当数据准备好时，进程会收到一个 SIGIO 信号，可以在信号处理函数中调用 I/O 操作函数处理数据。

优点：线程并没有在等待数据时被阻塞，内核直接返回调用接收信号，不影响进程继续处理其他请求因此可以提高资源的利用率。

缺点：信号 I/O 在大量 IO 操作时可能会因为信号队列溢出导致没法通知。

异步阻塞：程序进程向内核发送IO调用后，不用等待内核响应，可以继续接受其他请求，内核收到进程请求后
进行的IO如果不能立即返回，就由内核等待结果，直到IO完成后内核再通知进程。

异步 I/O 模型 (asynchronous IO)

异步I/O 与 信号驱动I/O最大区别在于，信号驱动是内核通知用户进程何时开始一个I/O操作，而异步I/O是由内核通知用户进程I/O操作何时完成，两者有本质区别,相当于不用去饭店场吃饭，直接点个外卖，把等待上菜的时间也给省了。

相对于同步I/O，异步I/O不是顺序执行。用户进程进行aio_read系统调用之后，无论内核数据是否准备好，都会直接返回给用户进程，然后用户态进程可以去做别的事情。等到socket数据准备好了，内核直接复制数据给进程，然后从内核向进程发送通知。IO两个阶段，进程都是非阻塞的。

信号驱动IO当内核通知触发信号处理程序时，信号处理程序还需要阻塞在从内核空间缓冲区拷贝数据到用户空间缓冲区这个阶段，而异步IO直接是在第二个阶段完成后，内核直接通知用户线程可以进行后续操作了。

优点：异步 I/O 能够充分利用 DMA 特性，让 I/O 操作与计算重叠

缺点：要实现真正的异步 I/O，操作系统需要做大量的工作。目前 Windows 下通过 IOCP 实现了真正的异步 I/O，在 Linux 系统下，Linux 2.6才引入，目前 AIO 并不完善，因此在 Linux 下实现高并发网络编程时以 IO 复用模型模式+多线程任务的架构基本可以满足需求。

Linux提供了AIO库函数实现异步，但是用的很少。目前有很多开源的异步IO库，例如libevent、libev、libuv。

异步非阻塞：程序进程向内核发送IO调用后，不用等待内核响应，可以继续接受其他请求，内核调用的IO如果
不能立即返回，内核会继续处理其他事物，直到IO完成后将结果通知给内核，内核在将IO完成的结果返回给进
程，期间进程可以接受新的请求，内核也可以处理新的事物，因此相互不影响，可以实现较大的同时并实现较
高的IO复用，因此异步非阻塞使用最多的一种通信方式。

五种 IO 对比

这五种 I/O 模型中，越往后，阻塞越少，理论上效率也是最优前四种属于同步 I/O，因为其中真正的 I/O 操作(recvfrom)将阻塞进程/线程，只有异步 I/O 模型才与 POSIX 定义的异步 I/O 相匹配

I/O 的具体实现方式

I/O常见实现

网络I/O复用模型常见的机制包括select、poll、epoll等。这些机制都提供了一种高效的方式来同时监控多个网络连接，从而提高系统的性能和稳定性。

Nginx支持在多种不同的操作系统实现不同的事件驱动模型，但是其在不同的操作系统甚至是不同的系统版本上面的实现方式不尽相同，主要有以下实现方式：

1、select：
select库是在linux和windows平台都基本支持的 事件驱动模型库，并且在接口的定义也基本相同，只是部
分参数的含义略有差异，最大并发限制1024，是最早期的事件驱动模型。I/O多路复用这个概念被提出来以
后， select于1983年第一个在BSD里面实现
2、poll：
在Linux 的基本驱动模型，windows不支持此驱动模型，是select的升级版，取消了最大的并发限制，在编
译nginx的时候可以使用--with-poll_module和--without-poll_module这两个指定是否编译select
库。poll出现在1997年
3、epoll：
epoll是库是Nginx服务器支持的最高性能的事件驱动库之一，是公认的非常优秀的事件驱动模型，它和
select和poll有很大的区别，epoll是poll的升级版，但是与poll有很大的区别.在2002年Davide 
Libenzi 实现了epoll.
epoll的处理方式是创建一个待处理的事件列表，然后把这个列表发给内核，返回的时候在去轮询检查这个
表，以判断事件是否发生，epoll支持一个进程打开的最大事件描述符的上限是系统可以打开的文件的最大
数，同时epoll库的I/O效率不随描述符数目增加而线性下降，因为它只会对内核上报的"活跃"的描述符进行
操作。
4、kqueue：
用于支持BSD系列平台的高校事件驱动模型，主要用在FreeBSD 4.1及以上版本、OpenBSD 2.0级以上版
本，NetBSD级以上版本及Mac OS X 平台上，该模型也是poll库的变种，因此和epoll没有本质上的区别，
效效率和epoll相似
5、IOCP：
Windows系统上的实现方式，对应第5种（异步I/O）模型。
6、/dev/poll:
用于支持unix衍生平台的高效事件驱动模型，主要在Solaris 平台、HP/UX，该模型是sun公司在开发
Solaris系列平台的时候提出的用于完成事件驱动机制的方案，它使用了虚拟的/dev/poll设备，开发人员将
要见识的文件描述符加入这个设备，然后通过ioctl()调用来获取事件通知，因此运行在以上系列平台的时候
请使用/dev/poll事件驱动机制。效率和epoll相似
7、rtsig：
不是一个常用事件驱动，最大队列1024，不是很常用
8、eventport：
该方案也是sun公司在开发Solaris的时候提出的事件驱动库，只是Solaris 10以上的版本，该驱动库可防
止内核崩溃等情况的发生。

常用I/O实现比较

Select：
实现过程 
1. 从用户空间将fd_set拷贝到内核空间
2. 注册回调函数
3. 调用其对应的poll方法
4. poll方法会返回一个描述读写是否就绪的mask掩码，根据这个mask掩码给fd_set赋值。
5. 如果遍历完所有的fd都没有返回一个可读写的mask掩码，就会让select的进程进入休眠模式，直到发现
可读写的资源后，重新唤醒等待队列上休眠的进程。如果在规定时间内都没有唤醒休眠进程，那么进程会被唤
醒重新获得CPU，再去遍历一次fd。
6. 将fd_set从内核空间拷贝到用户空间
优点:
POSIX所规定，目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点
缺点
单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024，可以通过修改宏定义
FD_SETSIZE，再重新编译内核实现，但是这样也会造成效率的降低
单个进程可监视的fd数量被限制，默认是1024，修改此值需要重新编译内核
对socket是线性扫描，即采用轮询的方法，效率较低 
select 采取了内存拷贝方法来实现内核将 FD 消息通知给用户空间，这样一个用来存放大量fd的数据结
构，这样会使得用户空间和内核空间在传递该结构时复制开销大 

poll：
实现过程本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态
其没有最大连接数的限制，原因是它是基于链表来存储的
大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义 
poll特点是"水平触发"，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd 
select是边缘触发即只通知一次
epoll：
在Linux 2.6内核中提出的select和poll的增强版本
支持水平触发LT和边缘触发ET
最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就绪态，并且只会通知一次 
使用"事件"的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调
机制来激活该fd，epoll_wait便可以收到通知 
优点:
1)没有最大并发连接的限制：能打开的FD的上限远大于1024(1G的内存能监听约10万个端口)，具体查
看/proc/sys/fs/file-max，此值和系统内存大小相关
2)效率提升：非轮询的方式，不会随着FD数目的增加而效率下降;只有活跃可用的FD才会调用callback函
数，即epoll最大的优点就在于它只管理"活跃"的连接，而跟连接总数无关
3)内存拷贝，利用mmap(Memory Mapping)加速与内核空间的消息传递;即epoll使用mmap减少复制开销 
缺点:
只有linux支持。在BSD上面对应的实现是kqueue。

总结

1、epoll只是一组API，比起select这种扫描全部的文件描述符，epoll只读取就绪的文件描述符
2、epoll比select等多路复用方式来说，减少了遍历循环及内存拷贝的工作量，因为活跃连接只占总并发连
接的很小一部分。
3、epoll基于事件的就绪通知机制，使用回调机制,所以性能比较好
4、基于epoll的IO多路复用减少了进程间切换的次数，使得操作系统少做了相对于用户任务来说的无用功。

I/O 选择

完全跨平台，可以使用select、poll。但是性能较差

针对不同操作系统自行选择支持的最优技术，比如: Linux选用epoll，Mac选用kqueue，Windows 选

用IOCP，提高IO处理的性能

示例: 最大并发连接数和内存有直接关系

[root@ubuntu2404 ~]#free -h
               total        used        free      shared  buff/cache   available
Mem:           1.9Gi       391Mi       1.4Gi       1.2Mi       270Mi       1.5Gi
Swap:          3.8Gi          0B       3.8Gi
[root@ubuntu2404 ~]#cat /proc/sys/fs/file-max
9223372036854775807

示例: select 和epoll 帮助

[root@ubuntu2404 ~]#whatis epoll
epoll (7)            - I/O event notification facility
[root@ubuntu2404 ~]#whatis select
select (2)           - synchronous I/O multiplexing
[root@ubuntu2404 ~]#whatis poll
poll (2)             - wait for some event on a file descriptor

结论

选择Nginx还是Apache很大程度上取决于具体的应用场景和个人偏好。如果你的应用主要涉及静态资源或者你需要一个高效的反向代理服务器，那么Nginx可能是更好的选择。而如果你正在寻找一个功能丰富且易于使用的Web服务器，并且你的应用不经常遇到极端的并发情况，Apache也是一个不错的选择。

无论最终选择了哪一个作为你的Web服务器，请确保对其进行适当的优化和维护以保障最佳性能。希望这篇文章可以帮助你在Nginx和Apache之间做出明智的选择！