标签：BIO 请求 04 worker Nginx 进程 解析 客户端
Nginx进程模型解析
- master进程: 主进程
- worker进程: 工作进程
默认是一个主进程, 一个工作进程, Nginx的工作进程是可以通过配置文件进行修改的
# 工作进程数量
worker_processes 1;
修改nginx.conf配置, 修改为2
记得每次修改完成配置文件都进行检查一下, 避免发生错误
检查完成没有问题, 就可以重启Nginx了, 修改完成Nginx必须重启, 不然配置无法生效
重启完成后,再次查看, 工作进程变成了2个
执行过程
客户端发送请求到Master, 然后通过master进行请求分发, 到不同的worker, 然后通过worker与client进行交互
Worker抢占机制
worker在与client交互的过程中, 会需要进行锁的抢占, 谁争取到了,就进行处理, 没有争取到的进入等待
传统服务器事件处理
在传统的事件服务器中, 一个工作进程只能在同一时间处理一个客户端的请求, 一旦发生阻塞, 那么就需要开启新的进程处理新的请求, 这是典型的BIO同步阻塞模型, 缺点也非常明显, 在有大量请求过来的时候, 一旦发生阻塞, 就会开启大量的线程,造成资源的浪费和CPU标高问题, 这也是BIO的典型问题
Nginx事件处理
在Nginx的事件处理中, 一个工作进程可以在同一时间处理多个客户端的请求, 一个客户端请求发生阻塞, 并不会影响到该进程处理其他的请求, 这就是为了解决BIO的问题, 所产生的NIO同步非阻塞模型, 解决了BIO模型的痛点, 那就是一个工作进程只能处理, 一个客户端请求的问题, 在Linux上采用epoll也就是多路复用技术, 很明显的提高了性能和请求的并发量
那么如何配置这个客户端的最大连接数呢
events {
# 默认使用 use epoll
use epoll;
# 每个worker允许的客户端最大连接数, 默认为1024, 可以修改
worker_connections 1024;
}
没错, 记得修改完之后重启一下nginx
标签：BIO,请求,04,worker,Nginx,进程,解析,客户端 来源： https://www.cnblogs.com/flower-dance/p/16662860.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。