IO 5つの機種を選択し、ファイルディスクリプタの作品（導入nginxの）

ユーザーエクスペリエンス速度1-3-10原則

パフォーマンスへの影響

多くの研究が、パフォーマンスは、ユーザーの行動に大きな影響を持っていることを示している：
ユーザーの79％は再びそれが遅いサイトを開くことはほとんどありませんと述べ
、ユーザーの47％がWebページが2秒未満でロードすることができます期待してい
40％ユーザーの負荷を3秒以上は、それが現場放棄するかどうかと言った
ページの読み込み時間が1秒の遅延が7％の変換損失、ページビューの％の減少につながる可能性がある11 
8第二法則：ユーザーは、ウェブサイトにアクセスしたときに、待機ページの場合以上8秒開いて、ユーザーの30％以上が待っているあきらめがあるでしょう

いくつかの要因がユーザーエクスペリエンスに影響を与えます

クライアントのハードウェア構成
クライアントネットワーク率
からクライアントとサーバ
サーバ・ネットワーク・レート
サーバーのハードウェア構成 
サーバーアーキテクチャの設計
操作のサーバアプリケーションモード
サーバー同時の数
サーバーの応答ファイルのサイズ計数
サーバーのI / Oの圧力

httpdのMPM

MPMのhttpd：
prefork：プロセス・モデル、2段構成、マスター子プロセスを生成するための責任を負う主プロセス、要求に応答する責任各子
worker：スレッドモデル、三次構造、マスタ子プロセスを生成するための責任を負う主プロセス、それぞれの子プロセス複数のスレッドは、要求に応じて、各スレッドの生成の原因である
スレッドモデル、三次構造、複数の要求に応答してサブプロセスは、各サブプロセスを生成するための責任を負う主要マスタープロセス：eventを

負荷平均：ロードあたり1/5/15分topコマンドは、現在のマシン、負荷の長い起動時間を表示します。

側処理ネットワークサービス要求手順

図1に示すように、コンピュータ中央入力/出力、IOPS（入力/出力毎秒）、すなわちO毎秒（又は書き込みサイクル）、メインディスクの性能尺度のいずれかでI / O。IOPSシステムはI / O要求を処理できる時間の単位を指し、一般ユニットの数、I / Oへの第二のI / O要求当たりの処理の数は、典型的には、データ操作要求を読み取りまたは書き込み要求します。

2、完全なI / Oはカーネル・データ・ユーザ空間プロセスデータとカーネル空間のパケットの完全な交換が、カーネル空間およびユーザ空間は厳密に隔離されているので、データ交換プロセスは、ユーザ空間ではないのでプロセスデータは、直接カーネルメモリ空間を呼び出すが、そう単純にI / Oメモリデータのうちコピーユーザプロセスのメモリ空間はユーザ空間にカーネル空間からデータをコピーすることであるとカーネル空間からのメモリデータを通過する必要がありますプロセスにおけるそれらのメモリ。

通信ネットワークは、ユーザ空間プロセスにネットワーク・プロトコル・スタックは、ネットワークIO IOであります

データのロードが完了した後3は、ディスクI / Oは、カーネルへのシステムコールによって開始されるプロセスである、そのようなディスク上のファイルや画像などのリソースを要求し、その後、適切なターゲット・カーネルドライバによる画像は、カーネルメモリ空間にロード待つために、比較的大規模なデータが必要であれば、その後、プロセスメモリにカーネルメモリからコピーされました。

PIO：産業連関表プログラム。

側処理ネットワークサービス要求手順

  データ取得要求を、サーバとの接続を確立するためのクライアント要求は、サーバは、要求（1-3）受け付ける
応答が完了構築されるまで、構築応答、サーバが終了要求、およびユーザ空間内のクライアントからの処理要求を受信する（図4）
戻りデータをI / Oバッククライアント（5-7）に送信されるネットワークを介して構築カーネル空間に応じて、サーバ

I / Oの紹介

ネットワークIO：基本的にソケットファイルの読み込み

ディスクIO：

二つの相を介してであると、各IOを。

最初のステップ：データファイルのデータの準備ができるまで、カーネルメモリ空間（バッファ）からロードすることが、長い時間
ステップ2：コピーカーネルバッファからデータをユーザプロセスのメモリ空間に、時間短いです

I/O模型

同期/非同期：懸念は、メッセージ通信機構であります

同步：synchronous，调用者等待被调用者返回消息，才能继续执行
异步：asynchronous，被调用者通过状态、通知或回调机制主动通知调用者被调用者的运行状态

阻塞/非阻塞：关注调用者在等待结果返回之前所处的状态

阻塞：blocking，指IO操作需要彻底完成后才返回到用户空间，调用结果返回之前，调用者被挂起
非阻塞：nonblocking，指IO操作被调用后立即返回给用户一个状态值，无需等到IO操作彻底完成，最终的调用结果返回之前，调用者不会被挂起

I/O模型：

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

同步阻塞IO模型　

阻塞原理：

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

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

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

优缺点：

优点：程序简单，在阻塞等待数据期间进程/线程挂起，基本不会占用 CPU 资源。
缺点：每个连接需要独立的进程/线程单独处理，当并发请求量大时为了维护程序，内存、线程切换开销较大，这种模型在实际生产中很少使用，apache 的preforck使用的是这种模式。

同步阻塞：

程序向内核发送IO请求后一直等待内核响应，如果内核处理请求的IO操作不能立即返回,则进程将一直等待并不再接受新的请求，并由进程轮训查看IO是否完成，完成后进程将IO结果返回给Client，

在IO没有返回期间进程不能接受其他客户的请求，而且是有进程自己去查看IO是否完成，这种方式简单，但是比较慢，用的比较少。

同步非阻塞IO模型

非阻塞原理：

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

同步非阻塞：

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

IO多路复用模型

IO多路复用原理：

1、IO多路复用（IO Multiplexing) ：是一种机制，程序注册一组socket文件描述符给操作系统，表示“我要监视这些fd是否有IO事件发生，有了就告诉程序处理”。

2、IO多路复用是要和NIO一起使用的。NIO和IO多路复用是相对独立的。NIO仅仅是指IO API总是能立刻返回，不会被Blocking；而IO多路复用仅仅是操作系统提供的一种便利的通知机制。操作系统并不会强制这俩必须得一起用，可以只用IO多路复用 + BIO，这时还是当前线程被卡住。IO多路复用和NIO是要配合一起使用才有实际意义。

3、IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取，就通知该进程。

4、多个连接共用一个等待机制，本模型会阻塞进程，但是进程是阻塞在select或者poll这两个系统调用上，而不是阻塞在真正的IO操作上。

5、用户首先将需要进行IO操作添加到select中，同时等待select系统调用返回。当数据到达时，IO被激活，select函数返回。用户线程正式发起read请求，读取数据并继续执行。

注意：Apache prefork是此模式1 的select，work是poll模式。

1、从流程上来看，使用select函数进行IO请求和同步阻塞模型没有太大的区别，甚至还多了添加监视IO，以及调用select函数的额外操作，效率更差。并且阻塞了两次，但是第一次阻塞在select上时，select可以监控多个IO上是否已有IO操作准备就绪，即可达到在同一个线程内同时处理多个IO请求的目的。而不像阻塞IO那种，一次只能监控一个IO。

2、虽然上述方式允许单线程内处理多个IO请求，但是每个IO请求的过程还是阻塞的（在select函数上阻塞），平均时间甚至比同步阻塞IO模型还要长。如果用户线程只是注册自己需要的IO请求，然后去做自己的事情，等到数据到来时再进行处理，则可以提高CPU的利用率。

3、IO多路复用是最常使用的IO模型，但是其异步程度还不够“彻底”，因它使用了会阻塞线程的select系统调用。因此IO多路复用只能称为异步阻塞IO模型，而非真正的异步IO

信号驱动IO模型　

信号驱动IO模型原理：

信号驱动IO：signal-driven I/O

1、用户进程可以通过sigaction系统调用注册一个信号处理程序，然后主程序可以继续向下执行，当有IO操作准备就绪时，由内核通知触发一个SIGIO信号处理程序执行，然后将用户进程所需要的数据从内核空间拷贝到用户空间。

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

3、对于 TCP 而言，信号驱动的 I/O 方式近乎无用，因为导致这种通知的条件为数众多，每一个来进行判别会消耗很大资源，与前几种方式相比优势尽失。

优点：线程并没有在等待数据时被阻塞，可以提高资源的利用率。
缺点：信号 I/O 在大量 IO 操作时可能会因为信号队列溢出导致没法通知。

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

异步IO（非阻塞）模型

原理：

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

2、由 POSIX 规范定义，应用程序告知内核启动某个操作，并让内核在整个操作（包括将数据从内核拷贝到应用程序的缓冲区）完成后通知应用程序。

优缺点：

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

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

五种I/O模型对比

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

I/O模型的具体实现

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标志位的数据结构来进行下一步处理。

缺点

1、单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024，可以通过修改宏定义FD_SETSIZE，再重新编译内核实现，但是这样也会造成效率的降低
2、单个进程可监视的fd数量被限制，默认是1024，修改此值需要重新编译内核
3、对socket是线性扫描，即采用轮询的方法，效率较低
4、select 采取了内存拷贝方法来实现内核将 FD 消息通知给用户空间，这样一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大

poll：

1、本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态
2、其没有最大连接数的限制，原因是它是基于链表来存储的
3、大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义
4、poll特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd
5、select是边缘触发即只通知一次

epoll：在Linux 2.6内核中提出的select和poll的增强版本

1、支持水平触发LT和边缘触发ET，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就需态，并且只会通知一次
2、使用“事件”的就绪通知方式，通过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减少复制开销

MMAP介绍

mmap()系统调用使得进程之间通过映射同一个普通文件实现共享内存。普通文件被映射到进程地址空间后，进程可以向访问普通内存一样对文件进行访问。

零拷贝

1、传统Linux中 I/O 的问题

2、传统的 Linux 系统的标准 I/O 接口（read、write）是基于数据拷贝的，也就是数据都是 copy_to_user 或者 copy_from_user，这样做的好处是，通过中间缓存的机制，减少磁盘 I/O 的操作，但是坏处也很明显，大量数据的拷贝，用户态和内核态的频繁切换，会消耗大量的 CPU 资源，严重影响数据传输的性能，统计表明，在Linux协议栈中，数据包在内核态和用户态之间的拷贝所用的时间甚至占到了数据包整个处理流程时间的57.1%。

什么是零拷贝？

零拷贝就是上述问题的一个解决方案，通过尽量避免拷贝操作来缓解 CPU 的压力。零拷贝并没有真正做到“0”拷贝，它更多是一种思想，很多的零拷贝技术都是基于这个思想去做的优化。