影响用户体验的几个因素
客户端硬件配置
客户端网络速率
客户端与服务端距离
服务端网络速率
服务端硬件配置
服务端架构设计
服务端应用程序工作模式
服务端并发数量
服务端响应文件大小及数量
服务端I/O压力 httpd应用程序工作模式
Apache prefork模型
预派生模式，有一个主控制进程，然后生成多个子进程，使用select模型，最大并发1024，每个子进程有一个独立的线程响应用户请求，相对比较占用内存，但是比较稳定，可以设置最大和最小进程数，是最古老的一种模式，也是最稳定的模式，适用于访问量不是很大的场景。 优点：稳定 缺点：大量用户访问慢，占用资源，1024个进程不适用于高并发场景。
Apache woker模型
一种多进程和多线程混合的模型，有一个控制进程，启动多个子进程，每个子进程里面包含固定的线程，使用线程程来处理请求，当线程不够使用的时候会再启动一个新的子进程，然后在进程里面再启动线程处理请求，由于其使用了线程处理请求，因此可以承受更高的并发。 优点：相比prefork 占用的内存较少，可以同时处理更多的请求 缺点：使用keepalive的长连接方式，某个线程会一直被占据，即使没有传输数据，也需要一直等待到超时才会被释放。如果过多的线程，被这样占据，也会导致在高并发场景下的无服务线程可用。（该问题在prefork模式下，同样会发生）
Apache event模型
Apache中最新的模式，2012年发布的apache 2.4.X系列正式支持event 模型，属于事件驱动模型(epoll)，每个进程响应多个请求，在现在版本里的已经是稳定可用的模式。它和worker模式很像，最大的区别在于，它解决了keepalive场景下，长期被占用的线程的资源浪费问题（某些线程因为被keepalive，空挂在哪里等待，中间几乎没有请求过来，甚至等到超时）。event MPM中，会有一个专门的线程来管理这些keepalive类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放。这样增强了高并发场景下的请求处理能力。
优点：单线程响应多请求，占据更少的内存，高并发下表现更优秀，会有一个专门的线程来管理keep-alive类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放。
缺点：没有线程安全控制。
Apache线程验证方式：
#Centos系统
[root@localhost ~]# httpd -V AH00558: httpd: Could not reliably determine the server's fully qualified domain name,
using localhost.localdomain. Set the 'ServerName' directive globally to suppress this
message
Server version: Apache/2.4.6 (CentOS)
Server built: Aug 8 2019 11:41:18
Server's Module Magic Number: 20120211:24
Server loaded: APR 1.4.8, APR-UTIL 1.5.2
Compiled using: APR 1.4.8, APR-UTIL 1.5.2
Architecture: 64-bit
Server MPM: prefork #MPM模式为prefork
threaded: no
# ps -ef | grep httpd
1.2.4.3：服务端I/O：
I/O在计算机中指Input/Output， IOPS (Input/Output Per Second)即每秒的输入输出量(或读写次数)，是衡量磁盘性能的主要指标之一。IOPS是指的是在单位时间内系统能处理的I/O请求数量，一般以每秒处理的I/O请求数量为单位，I/O请求通常为读或写数据操作请求。
root 2757 1 0 04:03 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 2758 2757 0 04:03 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 2759 2757 0 04:03 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 2760 2757 0 04:03 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 2761 2757 0 04:03 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 2762 2757 0 04:03 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
root 2786 2369 0 04:13 pts/0 00:00:00 grep --color=auto httpd
# cat /proc/2760/status //查看进程详情
Name: httpd
State: S (sleeping)
..............
Threads: 1 //线程数
..............
#Ubuntu 18.04.3系统：
root@mq-node1:~# apachectl -V
Server version: Apache/2.4.29 (Ubuntu)
Server built: 2019-09-16T12:58:48
Server's Module Magic Number: 20120211:68
Server loaded: APR 1.6.3, APR-UTIL 1.6.1
Compiled using: APR 1.6.3, APR-UTIL 1.6.1
Architecture: 64-bit
Server MPM: event #MPM模式为event
threaded: yes (fixed thread count)
forked: yes (variable process count)
# ps -ef | grep apache2
root 918 1 0 20:08 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 919 918 0 20:08 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 920 918 0 20:08 ? 00:00:00 /usr/sbin/apache2 -k start
root 1202 1172 0 20:12 pts/0 00:00:00 grep --color=auto apache2 httpd修改工作模型
~]# vim /etc/httpd/conf.modules.d/00-mpm.conf
# Select the MPM module which should be used by uncommenting exactly
# one of the following LoadModule lines:
# prefork MPM: Implements a non-threaded, pre-forking web server
# See: http://httpd.apache.org/docs/2.4/mod/prefork.html
#LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
# worker MPM: Multi-Processing Module implementing a hybrid
# multi-threaded multi-process web server
# See: http://httpd.apache.org/docs/2.4/mod/worker.html
#
#LoadModule mpm_worker_module modules/mod_mpm_worker.so
# event MPM: A variant of the worker MPM with the goal of consuming
# threads only for connections with active processing
# See: http://httpd.apache.org/docs/2.4/mod/event.html
#
LoadModule mpm_event_module modules/mod_mpm_event.so //修改为工作模式为event 重启服务
]# systemctl restart httpd 服务端I/O
一次完整的I/O是用户空间的进程数据与内核空间的内核数据的报文的完整交换过程，但是由于内核空间与用户空间是严格隔离的，所以其数据交换过程中不能由用户空间的进程直接调用内核空间的内存数据，而是需要经历一次从内核空间中的内存数据copy到用户空间的进程内存当中，所以简单说一次I/O就是把数据从内核空间中的内存数据复制到用户空间中进程的内存当中的整个过程。
而网络通信就是从网络协议栈到用户空间进程的IO，也就是网络IO。
磁盘I/O是进程向内核发起系统调用，请求磁盘上的某个资源比如是文件或者是图片，然后内核通过相应的驱动程序将目标图片加载到内核的内存空间，加载完成之后把数据从内核内存再复制给进程内存，如果是比较大的数据也需要等待时间。
每次IO，都要经由两个阶段：
第一步：将数据从磁盘文件先加载至内核内存空间（缓冲区），此步骤需要等待数据准备完成，时间较长
第二步：将数据从内核缓冲区复制到用户空间的进程的内存中，时间较短 系统I/O模型
同步/异步
关注的是事件处理的消息通信机制，即在等待一件事情的处理结果时，被调用者是否提供完成通知。
同步：synchronous，调用者等待被调用者返回消息后才能继续执行，如果被调用者不提供消息返回则为同步，同步需要调用者主动询问事情是否处理完成。
异步：asynchronous，被调用者通过状态、通知或回调机制主动通知调用者，即异步会主动返回被调用者的状态给调用者。
同步：进程发出请求调用后，内核不提供通知机制，即文件IO处理完成后不通知进程，需要进程自己去问内核是否处理完成。
异步：进程发出请求调用后，内核会在调用处理完成后返回调用结果给进程,Nginx是异步的。
阻塞/非阻塞
关注调用者在等待结果返回之前所处的状态
阻塞：blocking，指IO操作需要彻底完成后才返回到用户空间，调用结果返回之前，调用者被挂起，干不了别的事情。
非阻塞：nonblocking，指IO操作被调用后立即返回给用户一个状态值，无需等到IO操作彻底完成，最终的调用结果返回之前，调用者不会被挂起，可以去做别的事情。
系统IO模型组合
以我去吃饭为例：我点了10个包子
同步与异步：
我点包子之后厨师是否告诉我：
同步：厨师做好包子后会放到指定位置，但是做好包子之前需要自己一次次去看包子做好没有，厨师不会在包子做好之后通知我。
异步：厨师做好包子后告诉我包子做好放哪了。
阻塞与非阻塞：：
我点包子后的状态：
阻塞：在厨师做包子期间一直在包子盘子前面等着，不能干别的事情。
非阻塞：点完包子就可以去干别的事情，比如去逛逛街或者买买买。
IO模型组合：
同步阻塞：我点完包子后不能去做别的事情，而且不知道包子有没有做好，需要自己一直等着并一次次的问厨师做好没有。
同步非阻塞：点完包子后可以去做别的事情，但是不能长时间做别的事情，因为我还是不知道包子有没有做好，也要自己一直等着并一次次的问厨师做好没有，只能抽空做点别的。
异步阻塞：我点完包子后不能去走做别的事情，但是厨师在做好包子后会告诉我，也就是我不用再一次次为厨师包子有没有做好了。
异步非阻塞：我点完包子后可以做别的事情，而且可以一直在做别的去事情，因为厨师在做好包子后会告诉我。
网络I/O模型
阻塞型、非阻塞型、复用型、信号驱动型、异步
同步阻塞型IO模型（blocking IO）
阻塞IO模型是最简单的IO模型，用户线程在内核进行IO操作时被阻塞
用户请求到达系统服务进程，然后进程通过系统调用read向内核发起IO读操作，即将用户请求由用户空间转到内核空间，内核接收到IO请求后开始从磁盘读取文件到内核内存，即在等用户请求的文件从磁盘到达内核内存后，然后将接收的数据拷贝到用户空间，然后完成read操作。
用户请求需要等待内核将数据读取到进程内存后，处理用户的进程才可以继续处理该请求，整个IO请求的过程中，请求进程是被阻塞的，这导致进程在发起IO请求时，不能做任何事情，而且对CPU的资源利用率不够。
优点：程序简单，在阻塞等待数据期间进程挂起，基本不会占用 CPU 资源 缺点：每个连接需要独立的进程单独处理，当并发请求量大时为了维护程序，内存、进程切换开销较大，apache 的preforck使用的是这种模式。
同步阻塞：程序向内核发送IO请求后一直等待内核响应，如果内核处理请求的IO操作不能立即返回,则进程将一直等待并不再接受新的请求，并由进程轮训查看IO是否完成，完成后进程将IO结果返回给Client，在IO没有返回期间进程不能接受其他客户的请求，而且是有进程自己去查看IO是否完成，这种方式简单，但是比较慢，用的比较少。
同步非阻塞型I/O模型(nonblocking IO)
用户请求进程向内核发起IO请求时立即返回，但并未读取到任何数据，进程需要不断地发起IO请求，直到数据到达进程空间的内存后，才真正读取到数据并继续执行，即前期需要一次次 “轮询”去查看请求是否数据是否准备报，但是此机制存在两个问题：1.如果有大量文件描述符都要等，那么就得一个一个的read，这会带来大量的ContextSwitch（read是系统调用，每调用一次就得在用户态和核心态切换一次），2.轮询的时间不好把握，这里是要猜多久之后数据才能到，等待时间设的太长，程序响应延迟就过大，但是设的太短，就会造成过于频繁的重试，干耗CPU而已，所以是比较浪费CPU的方式，因此一般很少直接使用这种模型，而是在其他IO模型中使用非阻塞IO这一特性。
同步非阻塞：应用进程向内核发送请IO求后一直等待内核响应，如果内核处理请求的IO操作不能立即返回IO结果，进程将不再等待，而且继续处理其他请求，但是仍然需要进程隔一段时间就要查看内核IO是否完成。
IO多路复用型(IO multiplexing)
IO multiplexing就是我们说的select，poll，epoll，有些地方也称这种IO方式为event driven IO(事件驱动IO)，select/poll/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select，poll，epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。 当用户进程调用了select，那么整个进程会被block，而同时，kernel会“监视”所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回，这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。
Apache prefork是此模式的主进程+多进程/单线程+select，work是主进程+多进程/多线程+poll模式
信号驱动式IO(signal-driven IO)
信号驱动IO：signal-driven I/O 用户进程可以通过sigaction系统调用注册一个信号处理程序，然后进程可以继续向下执行，当有IO操作准备就绪时，由内核通知触发一个SIGIO信号处理程序执行，然后将用户进程所需要的数据从内核空间拷贝到用户空间， 此模型的优势在于等待数据报到达期间进程不被阻塞，进程可以继续执行，只要等待来自信号处理函数的通知。 优点：进程没有在等待数据时被阻塞，内核直接返回调用接收信号，不影响进程继续处理，其他请求因此可以提高资源的利用率。
缺点：信号 I/O 在大量 IO 操作时可能会因为信号队列溢出导致没法通知
异步阻塞：进程向内核发送IO调用后，不用等待内核响应，可以继续接受其他请求，内核收到进程请求后进行的IO如果不能立即返回，就由内核等待结果，直到IO完成后内核再通知进程，apache event模型就是主进程+多进程/多线程+信号驱动。
异步(非阻塞) IO(asynchronous IO)
相对于同步IO，异步IO不是顺序执行，用户进程进行aio_read系统调用之后，无论内核数据是否准备好，都会直接返回给用户进程，然后用户态进程可以去做别的事情，等到socket数据准备好了，内核直接复制数据给进程，然后从内核向进程发送通知，异步非阻塞IO的两个阶段，进程都是非阻塞的。 Linux提供了AIO库函数实现异步，但是用的很少，目前有很多开源的异步IO库，例如libevent、libev、libuv等，异步过程如下图所示：
异步非阻塞：程序进程向内核发送IO调用后，不用等待内核响应，可以继续接受其他请求，内核调用的IO如果不能立即返回，内核会继续处理其他事物，直到IO完成后将结果通知给内核，内核在将IO完成的结果返回给进程，期间进程可以接受新的请求，内核也可以处理新的事物，因此相互不影响，可以实现较大的同时并实现较高的IO复用，因此异步非阻塞使用最多的一种通信方式，nginx就是是异步非阻塞模型。
实现方式
Nginx支持在多种不同的操作系统实现不同的事件驱动模型，但是其在不同的操作系统甚至是不同的系统版本上面的实现方式不尽相同，主要有以下实现方式：
1、select：
select库是在linux和windows平台都基本支持的 事件驱动模型库，并且在接口的定义也基本相同，只是部分参数的含义略有差异，最大并发限制1024，是最早期的事件驱动模型。
2、poll：
在Linux 的基本驱动模型，windows不支持此驱动模型，是select的升级版，取消了最大的并发限制，在编译nginx的时候可以使用--with-poll_module和--without-poll_module这两个指定是否编译select库。
3、epoll：
epoll是库是Nginx服务器支持的最高性能的事件驱动库之一，是公认的非常优秀的事件驱动模型，它和select和poll有很大的区别，epoll是poll的升级版，但是与poll的效率有很大的区别.epoll的处理方式是创建一个待处理的事件列表，然后把这个列表发给内核，返回的时候在去轮训检查这个表，以判断事件是否发生，epoll支持一个进程打开的最大事件描述符的上限是系统可以打开的文件的最大数，同时epoll库的IO效率不随描述符数目增加而线性下降，因为它只会对内核上报的“活跃”的描述符进行操作。
4、rtsig：
不是一个常用事件驱动，最大队列1024，不是很常用
5、kqueue：
用于支持BSD系列平台的高校事件驱动模型，主要用在FreeBSD 4.1及以上版本、OpenBSD 2.0级以上版本，NetBSD级以上版本及Mac OS X 平台上，该模型也是poll库的变种，因此和epoll没有本质上的区别，都是通过避免轮训操作提供效率。
6、/dev/poll:
用于支持unix衍生平台的高效事件驱动模型，主要在Solaris 平台、HP/UX，该模型是sun公司在开发Solaris系列平台的时候提出的用于完成事件驱动机制的方案，它使用了虚拟的/dev/poll设备，开发人员将要见识的文件描述符加入这个设备，然后通过ioctl()调用来获取事件通知，因此运行在以上系列平台的时候请使用/dev/poll事件驱动机制。
7、eventport：
该方案也是sun公司在开发Solaris的时候提出的事件驱动库，只是Solaris 10以上的版本，该驱动库看防止内核崩溃等情况的发生。
8、Iocp：
Windows系统上的实现方式，对应第5种（异步I/O）模型。
常用模型汇总
常用模型通知对比
水平触发-- 多次通知，需要关心数据是否取完，即数据取走之后即不再通知进程，以避免重复多次无效通知，通知效率较低。
边缘触发-- 一次通知，需要关心数据是否取走，即只通知一次怎么保证数据被进程成功取走了，以避免数据丢失，通知效率较高。
Select：
POSIX所规定，目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点，本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理
缺点
单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024，可以通过修改宏定义FD_SETSIZE，再重新编译内核实现，但是这样也会造成效率的降低。
单个进程可监视的fd数量被限制，默认是1024，修改此值需要重新编译内核。
对socket是线性扫描，即采用轮询的方法，效率较低。
select 采取了内存拷贝方法来实现内核将 FD 消息通知给用户空间，这样一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大。
poll：
本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态。
其没有最大连接数的限制，原因是它是基于链表来存储的。
大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义。
poll特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。
epoll：
在Linux 2.6内核中提出的select和poll的增强版本。
支持水平触发LT和边缘触发ET，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就需态，并且只会通知一次使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知 。
优点:
没有最大并发连接的限制：能打开的FD的上限远大于1024(1G的内存能监听约10万个端口)，具体查看/proc/sys/fs/file-max，此值和系统内存大小相关。
效率提升：非轮询的方式，不会随着FD数目的增加而效率下降；只有活跃可用的FD才会调用callback函数，即epoll最大的优点就在于它只管理“活跃”的连接，而跟连接总数无关内存拷贝，利用mmap(Memory Mapping)加速与内核空间的消息传递；即epoll使用mmap减少复制开销。
MMAP介绍
mmap(memory mapping)系统调用使得进程之间通过映射同一个普通文件实现共享内存，普通文件被映射到进程地址空间后，进程可以像访问普通内存一样对文件进行访问。
传统方式copy数据
mmap方式
越学越感到自己的无知