nginx应用指南

nginx应用指南
-- 同步,异步,阻塞,非阻塞 -- IO模型介绍 -- nginx高并发原理 -- 为什么要绑定nginx到不同进程上

Web 服务:Apache  nginx   tomcat
网页:静态网页:  .html   .htm结尾  动态网页: .jsp   .php结尾
并发量: Apache:2W   nginx:5W   单Apache:同时处理客户端的理想值是2W
单nginx:同时处理客户端的理想值是5W
Ng inx 应⽤场景:静态处理,反向代理,负载均衡,资源缓存,安全防护,访问限制,访问认证
---
nginx 是一个高性能的 HTTP反向代理web服务器
众所周知nginx的相比于apache有更高的并发,可以接收处理更多的访问请求, 这得益于 IO模型
---
为什么 nginx apache 高效?
Nginx采用的epoll模型,有内存映射机制;apache用的是select模型,线性遍历inode号,效率低下
---
I/O介绍
每次 I/O,都要经由两个阶段
第一步 :将数据从磁盘文件先加载至内核空间(缓冲区),等待数据准备完成,时间较长
第二步:将数据从内核缓冲区复制到用户空间的进程的内存中,时间较短
---
壹:同步,异步,阻塞,非阻塞
同步 / 异步  关注是 被调用者 消息通信机制
阻塞 / 非阻塞:关注调用者在等待结果返回之前的状态
 
贰:IO模型介绍
同步 用户进程通过系统调用拿资源,因不确定是否拿到数据,所以会一次次的询问结果,这个过程是同步。
阻塞:将数据从磁盘拷贝到内核空间,再将内核中的数据复制到应用的用户空间,这个过程进程不能做其他事,即阻塞。
非阻塞:将数据从磁盘拷贝到内核空间,再将内核中的数据复制到应用的用户空间,这个过程进程可以做其他事,即非阻塞。
同步非阻塞:这个较同步阻塞没有改善,看似非阻塞,进程可以干其他事,但由于是同步,进程依旧在不断问询结果,反而更消耗资源。
(我可以做其他事,但是我还得一直问好了没)
IO 多路复用只能成为(异步阻塞模型):用户进程找一个代理select,而不直接与内核打交道,系统调用交于select进行处理。因阻塞在IO调用那里,但一个select可以检测多个IO模型,相比与同步阻塞只能检测一个提高了cpu的利用率。
(找个代理,代理面对多个io但是我得等)
信号驱动型 ( 异步半阻塞 ):即用户进程建立SIGIO的信号处理程序,复制数据从磁盘到内核空间,等处理完递交SIGIO告知用户进程,这个过程是不阻塞的状态。用户进程从内核空间复制到用户应用空间,这个过程是阻塞的。信号驱动并未完全解决问题,只是做到了一部分不阻塞,一部分阻塞。
(找个代理, 不用我从磁盘拷贝到内核,但是需要我从内核复制到用户空间)
异步 IO 模型 ( 异步非阻塞 ):用户进程不受阻塞,所有的请求,拿数据拷贝到应用空间都由内核完成,用户进程可以接收更多的用户请求。
叁:nginx高并发原理
nginx高并发使用的是epoll的方式,提供给用户访问,复制数据的一些操作交由内核完成。自身做的事情越少接待的用户请求就越多。
epoll在linux2.6中增加了内存拷贝mmap机制,加速与内核空间的消息传递,即内存映射。
内存映射机制:磁盘中有数据,数据有对应的inode,在内存中映射一个相同的
inode,大小也相同,下次拿数据不需要遍历inode,分析路径了。这样提高了效率。
 
select缺点: 1.能够监视⽂件描述符的数量存在最⼤限制  2.线性遍历扫描效率低下
epool模型: 1.每当FD就绪,采⽤系统的回调函数之间将fd放⼊,效率更⾼  2.最⼤连接⽆限制。
量级: 1.功能模块少  2.代码模块化
肆:为什么要绑定 Nginx 进程到不同的 CPU 上 ?
nginx多进程可能跑在某一个cpu或cpu某一个核上,导致进程使用硬件的资源不均。充分利用硬件多cpu多核资源目的。
cpu的个数不同绑定亲和力方法也不同 cpu亲和(affinity)
vim nging.conf
worker_processes 2; ##2核 
worker_cpu_affinity 01 10;
worker_processes 4; ## 4核 
worker_cpu_affinity 0001 0010 0100 1000;
CPU核⼼和Nginx⼯作进程绑定⽅式,把每个worker进程固定在⼀个cpu上执⾏,减少切换cpu 的 cache miss ,获得更好的性能。
 
为什么nginx比apache高效?
Nginx 用的是异步非阻塞, apache 用的是同步阻塞
apache:
每一个连接, apache就会创建一个进程,每个进程内单线程,apache最多能创建256个进程。对于一个负载相对较高的网站来说,256的进程,也就是256个线程,因为线程处理请求时,是同步阻塞模式,接收请求之后,会一直等待该请求读取程序文件(IO)(同步),执行业务逻辑,返回客户端,所有操作完成之后才能处理下一个请求(阻塞)如果服务器已经达到256的极限,那么接下去的访问就需要排队这也就是为什么某些服务器负载不高的原因了。
nginx:
nginx接收一个请求后,不会等待这个请求的文件读取操作完成之后才接收下一个请求,它不会等待这个请求的后续的处理结果。而是会马上循环处理下一个请求(不阻塞)。请求的程序文件执行完成之后,会主动通知该线程,不用你主动去等待或者轮询查看(异步)。最后返回给客户端。这样做,每个请求过来就不需要等待很长的时间排队,而是马上就能接收,开始进行处理了。等处理完成之后,会主动通知回调这个线程进行数据返回。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值