深度 | Nginx为什么快到停不下来?,
深度 | Nginx为什么快到停不下来?,
Nginx 的进程模型
Nginx 服务器,正常运行过程中:
思考:
HTTP 连接建立和请求处理过程
Nginx 高性能、高并发
Nginx 的事件处理模型
request:Nginx 中 http 请求。
基本的 HTTP Web Server 工作模式:
Nginx 也是这个套路,整体流程一致。
模块化体系结构
nginx的模块根据其功能基本上可以分为以下几种类型:
- event module: 搭建了独立于操作系统的事件处理机制的框架,及提供了各具体事件的处理。包括ngx_events_module, ngx_event_core_module和ngx_epoll_module等。nginx具体使用何种事件处理模块,这依赖于具体的操作系统和编译选项。
- phase handler: 此类型的模块也被直接称为handler模块。主要负责处理客户端请求并产生待响应内容,比如ngx_http_static_module模块,负责客户端的静态页面请求处理并将对应的磁盘文件准备为响应内容输出。
- output filter: 也称为filter模块,主要是负责对输出的内容进行处理,可以对输出进行修改。例如,可以实现对输出的所有html页面增加预定义的footbar一类的工作,或者对输出的图片的URL进行替换之类的工作。
- upstream: upstream模块实现反向代理的功能,将真正的请求转发到后端服务器上,并从后端服务器上读取响应,发回客户端。upstream模块是一种特殊的handler,只不过响应内容不是真正由自己产生的,而是从后端服务器上读取的。
- load-balancer: 负载均衡模块,实现特定的算法,在众多的后端服务器中,选择一个服务器出来作为某个请求的转发服务器。
常见问题剖析
Nginx vs. Apache
网络 IO 模型:
场景:
处理多个请求时,可以采用:IO 多路复用 或者 阻塞 IO +多线程
- IO 多路服用:一个 线程,跟踪多个 socket 状态,哪个就绪,就读写哪个;
- 阻塞 IO + 多线程:每一个请求,新建一个服务线程
思考:IO 多路复用 和 多线程 的适用场景?
- IO 多路复用:单个连接的请求处理速度没有优势,适合 IO 密集型 场景,事件驱动
- 大并发量:只使用一个线程,处理大量的并发请求,降低上下文环境切换损耗,也不需要考虑并发问题,相对可以处理更多的请求;
- 消耗更少的系统资源(不需要线程调度开销)
- 适用于长连接的情况(多线程模式长连接容易造成线程过多,造成频繁调度)
- 阻塞IO + 多线程:实现简单,可以不依赖系统调用,适合 CPU 密集型 场景
- 每个线程,都需要时间和空间;
- 线程数量增长时,线程调度开销指数增长
Nginx 最大连接数
基础背景:
因此,Nginx 的最大连接数:
思考:
每打开一个 socket 占用一个 fd
为什么,一个进程能够打开的 fd 数量有限制?
IO 模型
场景:
处理多个请求时,可以采用:IO 多路复用 或者 阻塞 IO +多线程
- IO 多路复用:一个 线程,跟踪多个 socket 状态,哪个就绪,就读写哪个;
- 阻塞 IO + 多线程:每一个请求,新建一个服务线程
思考:IO 多路复用 和 多线程 的适用场景?
- IO 多路复用:单个连接的请求处理速度没有优势
- 大并发量:只使用一个线程,处理大量的并发请求,降低上下文环境切换损耗,也不需要考虑并发问题,相对可以处理更多的请求;
- 消耗更少的系统资源(不需要线程调度开销)
- 适用于长连接的情况(多线程模式长连接容易造成线程过多,造成频繁调度)
- 阻塞IO + 多线程:实现简单,可以不依赖系统调用。
- 每个线程,都需要时间和空间;
- 线程数量增长时,线程调度开销指数增长
select/poll 和 epoll 比较
详细内容,参考:
- select poll epoll三者之间的比较
select/poll 系统调用:
- // select 系统调用
- int select(int maxfdp,fd_set *readfds,fd_set *writefds,fd_set *errorfds,struct timeval *timeout);
- // poll 系统调用
- int poll(struct pollfd fds[], nfds_t nfds, int timeout);
select:
- 查询 fd_set 中,是否有就绪的 fd,可以设定一个超时时间,当有 fd (File descripter) 就绪或超时返回;
- fd_set 是一个位集合,大小是在编译内核时的常量,默认大小为 1024
- 特点:
- 连接数限制,fd_set 可表示的 fd 数量太小了;
- 线性扫描:判断 fd 是否就绪,需要遍历一边 fd_set;
- 数据复制:用户空间和内核空间,复制连接就绪状态信息
poll:
- 解决了连接数限制:
- poll 中将 select 中的 fd_set 替换成了一个 pollfd 数组
- 解决 fd 数量过小的问题
- 数据复制:用户空间和内核空间,复制连接就绪状态信息
- epoll:event 事件驱动
epoll:event 事件驱动
- 事件机制:避免线性扫描
- 为每个 fd,注册一个监听事件
- fd 变更为就绪时,将 fd 添加到就绪链表
- fd 数量:无限制(OS 级别的限制,单个进程能打开多少个 fd)
select,poll,epoll:
Nginx 的并发处理能力
关于 Nginx 的并发处理能力:
- 并发连接数,一般优化后,峰值能保持在 1~3w 左右。(内存和 CPU 核心数不同,会有进一步优化空间)
评论暂时关闭