高性能のWEBサービスnginxの

I / Oの紹介

I / O:
ネットワークIO:読むために、基本的にソケットファイル
ディスクIO:
すべてのIOを、2つの段階を経てすべき:
データの準備ができるまで、データファイルカーネルメモリ領域(バッファ)からロードされる:最初のステップ、長い
ステップ2:ユーザプロセスのメモリ空間にカーネル・バッファからデータをコピーし、時間が短く、

I/O模型

同期/非同期:懸念がためのメッセージ通信メカニズムで
、同期、メッセージは、あなたが実行し続けることができ、呼び出し元に返されるのを待って、発信者:同期
、非同期:非同期を、状態、通知またはコールバック機構を介して、発信者は、発信者呼び出し先の動作状態を通知します
ブロッキング/ノンブロッキング:それは結果を待っ前に返された状態で、呼び出し元の注目
ブロック:IO操作が完了したが、完全にユーザ空間に戻る必要後、コールリターンを指しまでブロッキングは、呼び出し側は中断され
ノンブロッキング:ノンブロッキングは、を参照しますIO操作が完全に最終呼び出しが戻る前に完了IO操作を待たずに、すぐにユーザーにステータス値と呼ばれた後に返し、呼び出し側は中断されることはありません
I / Oモデル:
閉塞性、非ブロッキング、再使用、駆動、非同期信号

ノンブロッキングIOモデル

ブロッキングIOモデル

IO IOモデルをブロックする最も単純なモデルで、ユーザスレッドは、カーネルにIO操作をブロックされている
ユーザスレッドIOはスペースをカーネルにユーザ空間からシステムコールによって開始読み取り操作をお読みください。パケットがカーネルまで到着し、その後、ユーザ空間の中に受信したデータをコピーした後、読み出し動作が完了し
、受信したデータを処理するために、続行する前に、リードデータバッファを読み取るために待つようにユーザーに。IO要求を通じて、ユーザスレッドは、CPUリソースの使用率、開始IO要求は何もできないときにユーザーを導く、ブロックされていない
データブロックされた/中断されたスレッドを待っている間に簡単な手順、プロセス:利点実質的にないCPUリソース
欠点:大きなオーバーヘッドを切り替える保守手順、メモリ、スレッドの同時リクエストが大量に、このモデルはほとんど実際の生産に使用されていない場合には、単独で、各プロセス/スレッド処理、のための別個の接続を必要とします

シングルスレッドのネットワークサービスの場合、これは問題が立ち往生になります。待っているとき、全体のスレッドが中断されているので、それが行われ、また他の作業を行うことはできません。現代のオペレーティングシステムは、マルチタスク、タスクの切り替えを先制されているので、このブロックは、同時に実行には影響しません別のプログラム(プロセス)です。ここでのブロックブロックは、現在のプロセスを指し
、マルチスレッド、ネットワーク要求を扱う各として実装する必要があり、同時に複数のネットワーク要求に応えると同時に、ネットワーク・サービスの。同時接続の線形の数とスレッド数を増やします。2000年以前のネットワーク・サーバは、達成することがそんなにあります。より多くのスレッド、多くのコンテキストスイッチ、およびコンテキストスイッチが不CPUの多くを無駄に、比較的重い作業である。しかし、2つの問題があります。各スレッドは、スレッドのスタックとして、いくつかのメモリを取り上げる
の両方が同時スレッドプールによることができるが、それは多数のスレッドを生成しません、要求を処理します。しかし、これは同時接続の最大数を制限します。
あなたは取り扱い上のデータを持っているネットワーク要求を受け入れるように読んで呼び出すと、データが実際に何かをやっていないことにします。多数のスレッドを使用する理由は、単にブロックが起こるので、

ときにユーザスレッドが戻るとすぐにIO要求を開始します。しかし、ユーザスレッドが本当に続け、データを読み、データが到着するまではIO要求を開始し続けるために必要なすべてのデータを読み取れませんでした。または「ポーリング」のメカニズムは、
2つの問題がある:あなたがファイル記述子の数が多い場合、あなたは1回の読み取りを持って、待たなければなりません。これは、コンテキストスイッチ(、ユーザーモードとカーネルモードの切り替え時に呼び出す必要がありますたびにシステムコールを読んで)の多くをもたらすでしょう。ポーリング時間が十分に把握できません。ここでは、に到達するためにどのくらいのデータの後に推測することです。待ち時間が長すぎる、プログラムの応答遅れが大きすぎる設定されている。短すぎる設定し、それはあまりにも頻繁に再試行の原因になります、ドライことのCPU消費量は
めったに直接このモデルを使用して、CPUを無駄にするより方法ですが、他のモデルでは、ノンブロッキングIO IOを、この機能を使用します

IO信号駆動モデル

非同期IOモデル

ドライブはIO IOオペレーションはアプリケーションに通知するカーネルによって実行することができ、非同期IO操作が完了したときにIOユーザに知らせるカーネル・スレッドである場合、非同期IOとIO信号との間の主な違いは、信号駆動です。場合カーネルドライバ信号IO通知トリガ信号ハンドラ、信号ハンドラはさらに、非同期IOは、第二段階で直接行われている間、カーネルを直接通知する、この段階ではユーザ空間バッファをカーネル空間からデータをコピーするために、ブロッキング緩衝液中で必要ユーザは、その後の操作スレッドができる
カーネルに通知するために、アプリケーションによって定義されたPOSIX仕様は、動作を開始し、全体の動作と完了通知塗布後(のアプリケーション・コピーにカーネル・バッファからのデータを含む)コアを可能にする
利点:非同期Iは/ O DMAは、I / O操作に機能を利用することができますし、重複計算する
欠点を:真の非同期を実現するためのI / O、オペレーティング・システムは、多くの作業を行う必要があります。Linuxシステムの下で、Linuxの2.6を導入した真の非同期を達成するためにWindowsのIOCPを流れる電流は、I / O、現在のAIOは、このように+ IO多重化モデルマルチスレッド・モードへのLinuxの下で高い同時ネットワークプログラミングを達成し、完璧ではない場合にはアーキテクチャの基本的なニーズを満たします

具体I / Oモデル

这五种 I/O 模型中,越往后,阻塞越少,理论上效率也是最优前四种属于同步 I/O,因为其中真正的 I/O 操作(recvfrom)将阻塞进程/线程,只有异步 I/O 模型才与 POSIX 定义的异步 I/O 相匹配
主要实现方式有以下几种:
Select:Linux实现对应,I/O复用模型,BSD4.2最早实现,POSIX标准,一般操作系统均有实现
Poll:Linux实现,对应I/O复用模型,System V unix最早实现
Epoll:Linux特有,对应I/O复用模型,具有信号驱动I/O模型的某些特性
Kqueue:FreeBSD实现,对应I/O复用模型,具有信号驱动I/O模型某些特性
/dev/poll:SUN的Solaris实现,对应I/O复用模型,具有信号驱动I/O模型的某些特性
Iocp Windows实现,对应第5种(异步I/O)模型

select/poll/epoll

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减少复制开销

零拷贝

传统Linux中 I/O 的问题
传统的 Linux 系统的标准 I/O 接口(read、write)是基于数据拷贝的,也就是数据都是 copy_to_user 或者 copy_from_user,这样做的好处是,通过中间缓存的机制,减少磁盘 I/O 的操作,但是坏处也很明显,大量数据的拷贝,用户态和内核态的频繁切换,会消耗大量的 CPU 资源,严重影响数据传输的性能,统计表明,在Linux协议栈中,数据包在内核态和用户态之间的拷贝所用的时间甚至占到了数据包整个处理流程时间的57.1%
什么是零拷贝
零拷贝就是上述问题的一个解决方案,通过尽量避免拷贝操作来缓解 CPU 的压力。零拷贝并没有真正做到“0”拷贝,它更多是一种思想,很多的零拷贝技术都是基于这个思想去做的优化

nginx介绍

特性:
模块化设计,较好的扩展性
高可靠性
支持热部署:不停机更新配置文件,升级版本,更换日志文件
低内存消耗:10000个keep-alive连接模式下的非活动连接,仅需2.5M内存
event-driven,aio,mmap,sendfile

基本功能:
静态资源的web服务器
http协议反向代理服务器
pop3/imap4协议反向代理服务器
FastCGI(LNMP),uWSGI(python)等协议
模块化(非DSO),如zip,SSL模块

nginx架构

 

web服务相关的功能:
虚拟主机(server)
支持 keep-alive 和管道连接( 共享TCP连接发起并发的HTTP请求)
访问日志(支持基于日志缓冲提高其性能)
url rewrite
路径别名
基于IP及用户的访问控制
支持速率限制及并发数限制
重新配置和在线升级而无须中断客户的工作进程
Memcached 的 GET 接口

nginx的程序架构:
master/worker结构
一个master进程:
负载加载和分析配置文件、管理worker进程、平滑升级
一个或多个worker进程
处理并响应用户请求
缓存相关的进程:
cache loader:载入缓存对象
cache manager:管理缓存对象

nginx高度模块化,但其模块早期不支持DSO机制;1.9.11版本支持动态装载和卸载
模块分类:
核心模块:core module
标准模块:
•HTTP 模块: ngx_http_*
HTTP Core modules 默认功能
HTTP Optional modules 需编译时指定
•Mail 模块 ngx_mail_*
•Stream 模块 ngx_stream_*
第三方模块

nginx模块

核心模块:是 Nginx 服务器正常运行 必不可少 的模块,提供 错误日志记录 、 配置文件解析 、 事件驱动机制 、 进程管理 等核心功能
标准HTTP模块:提供 HTTP 协议解析相关的功能,比如: 端口配置 、 网页编码设置 、 HTTP响应头设置 等等
可选HTTP模块:主要用于扩展标准的 HTTP 功能,让 Nginx 能处理一些特殊的服务,比如: Flash 多媒体传输 、解析 GeoIP 请求、 网络传输压缩 、 安全协议 SSL 支持等
邮件服务模块:主要用于支持 Nginx 的 邮件服务 ,包括对 POP3 协议、 IMAP 协议和 SMTP协议的支持
第三方模块:是为了扩展 Nginx 服务器应用,完成开发者自定义功能,比如: Json 支持、 Lua 支持等

nginx的功用

静态的web资源服务器
html,图片,js,css,txt等静态资源
结合FastCGI/uWSGI/SCGI等协议反向代理动态资源请求
http/https协议的反向代理
imap4/pop3协议的反向代理
tcp/udp协议的请求转发(反向代理)

 

おすすめ

転載: www.cnblogs.com/quguwei/p/11323296.html