admin管理员组

文章数量:1576358

前面我们谈到了nginx怎么使用epoll运行自己的事件驱动框架的,那么这样的一个事件驱动框架到底会给我们带来怎样的一个好处?

我们来看下在请求切换的这样一个场景中,这种事件驱动框架给我们带来的争议;
　　在下面的这张图中,实际上有三个请求,蓝色的,绿色的还有橘黄色的;


每一个请求如果是一个HTTP请求的话,我们把它简化为三部分,比如说第一部分我们收到HTTP请求的header 那么收完header以后,我大致就知道我该交给上游的哪一台服务器去处理,应用一些负载均衡算法,那么接下来我可能会向上游服务器建立连接,或者说我本地处理的时候,我接下来会判断这个header中有没有Content-Length指明它可有body,如果含有body的情况下?我接下来会读下一个读事件,去处理完它所有的HTTPbody;那么处理完HTTPbody以后,我们可能还会向它发送一个HTTP响应,那么在这样的一个过程中,它实际上可能表现为三个事件,那么传统的服务,比如说Apache和Tomcat它们在处理的时候,是每一个进程,同一时间只处理一个请求,比如说process1在处理request1的时候,当request1目前网络事件不满足的情况下,就会切换到process2,就会处理process2上面的request2,而request2可能很快又不满足了,比如写一个响应的时候,发现缓存区都已经满了,也就是说网络中已经用拥塞了,所以说我们的滑动窗口已经没法向前滑动,以至于我们调write方法我们没有办法写入我们需要写入的这样一个字节,当write方法是非阻塞的时候,这个时候我们阻塞类的写方法,一定又会导致我们所在的进程又发生一次切换,现在切换到process3,操作系统选择了process3;因为process3上的 request3处于一个满足的状态;我们可以继续往下执行,在执行的过程中尼,process3可能用完了它的时间片,process3又被操作系统切换;又切换到process1;

如此往复下去;这里会有一个很大的问题,就是我们绿色的箭头在我们当前的CPU的频率下它所消耗的时间大概是5微妙,这个5微妙虽然很小,如果我们并发的连接数和并发的进程开始增加的时候,它不是一个线性增加,而是一个指数增加;所以当我们并发连接非常多的情况下,这个进程间的消耗是非常客观的,以至于消耗了绝大部分的计算能力,所以这种传统的WEB服务它在依赖操作系统的进程调度的方法去实现它的并发连接数,而操作系统的进程调度仅仅适用于很少量的数百 上千这样的进程间做切换;这样的低并发还能接收;再多 几万 几十万的情况下,就无法容忍了;

那么nginx是怎么处理的尼?

当蓝色的请求,处理事件不满足的情况下,它在用户态直接就切换到了绿色请求,这样,我们就没有了中间进程间切换的一个成本,因为网络事件不满足**,除非是我们nginx的worker进程所使用的时间片已经到了,而时间片的长度尼一般是5毫秒到800毫秒;所以我们在nginx的worker的配置上往往会把它的优先级加到最高,比如说我们通常会加到负的19,这样我们的静态优先级提高的比较高的的时候,往往操作系统给我们分的时间片是比较大的;这样我们的nginx才能比较好的在用户态完成请求的切换;使得CPU少做无用功**

现在我们了解了请求切换能够使nginx的性能更高,接下来我们看一看从我们写一段openresty LUA代码或者我们nginx在编程实现中怎样利用这样一个特性来达到非常高的性能的;

本文标签： Nginx

版权声明：本文标题：Nginx【19】Nginx的请求切换 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://m.elefans.com/xitong/1727803741a1130838.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。