Nginx架构篇之 Nginx和Apache的比较 (七)-张柏沛IT博客

正文内容

Nginx架构篇之 Nginx和Apache的比较 (七)

栏目:Linux 发布时间:2020-02-11 18:03 浏览量:140

Nginx事件

Nginx是一个事件驱动的框架。这里的事件主要指的是网络事件。每一个请求连接会对应两个网络事件,读事件和写事件。

这里说的连接以及之后说的连接都是指TCP三次握手之后建立的连接,只有当建立了这个连接之后http请求才能通过这个连接发送到服务端,可以将连接看做是一个通道,而请求是货物,请求要通过这个通道才能传到服务端,所以要先建立连接才能发送请求。这个连接在断开之前可以发送多个http请求(keepalive),当tcp四次分手时连接才断开。

我的理解是,当nginx在读取报文的时候属于读事件,返回响应时需要在报文中写入响应就是写事件,当然不止读取报文和返回响应,还有很多中情况。

nginx的事件循环过程:
nginx启动的时候,打开80或者443端口,它会等待事件生成,例如等待客户端的向服务器发起请求连接等。此时nginx进程处于sleep状态的。
当Linux处理完三次握手流程之后,连接就会成功建立,客户端的请求会随着而来,此时就会有一堆事件要处理。Linux内核会将这些事件做成队列交给nginx处理,此时nginx进程会被唤醒然后一个个的处理这些事件。
nginx在处理事件的时候可能又会生成一些新事件,比如返回响应会生成写事件。然后写新生成的事件又会被Linux放到队列中交给nginx处理。
等所有事件处理完之后,nginx进程判断出事件队列为空,就会又进入sleep状态。
请求越多,事件就会越多。


下面我们说一下为什么nginx比Apache效率高(搜的网上的资料)
在并发请求不高的情况下,nginx和Apache的性能是没有明显的区别的。而高并发的情况下nginx会比Apache快很多,这得益于nginx的epoll模型。

apache是多线程或者多进程,在工作的时候,每建立一个连接就会生成一个Apache子进程,一个进程接收(listen)–>识别处理—>返回请求,在此过程中,一个进程全程都在处理这个连接的请求,当处理请求时遇到阻塞(例如等待请求处理,等待响应)该进程要等待这个请求处理完才能去处理别的请求,相当于这个进程要干等着。那么一旦连接数很多,Apache必然要生成更多的进程来处理请求,一旦进程多了,CPU对于进程的切换就频繁了,很耗资源和时间,所以就导致apache性能下降了,说白了就是处理不过来这么多进程了。

对于Nginx,一个worker可以处理多个连接,不像Apache一个进程只能处理一个连接的请求,这得益于nginx的epoll模型(异步非阻塞模型)。一个worker子进程不会全程处理一个请求,处理到什么程度呢?处理到可能发生阻塞的地方,比如向上游(后端)服务器转发request,并等待请求返回,那么,这个处理的worker很聪明,他会在发送完请求后,注册一个事件,当上游服务处理完这个请求就会触发这个事件告诉worker进程继续回来处理这个请求。在等待上游服务返回响应的这段事件,这个worker进程不会像Apache的进程那样干等着,而是去处理别的请求。
而一旦上游服务器返回了,就会触发这个事件,worker才会来接手,这个request才会接着往下走。

woker进程一般设置为跟cpu核数一致。nginx的woker进程在同一时间可以处理的请求数只受内存限制,可以处理多个请求。

刚刚我们说客户端们会先和nginx建立连接,连接建立好了才会发送http请求,而实际上客户端是和nginx的worker进程建立连接,一个worker进程有其对应的连接池,这些连接池就是用来放客户端们与worker进程建立的连接,这个连接池可以“同时”容纳多少连接由nginx.conf中的 worker_connections 参数决定。而worker进程的个数由worker_processes参数决定,一般会设置为Linux的CPU核数。

所以nginx可以同时容纳的连接数(也就是并发连接数)为 worker进程数 * 每个worker进程连接池可容纳的连接数

例如 

worker_processes  4;

events {
    worker_connections  1024;
}

此时nginx服务器的并发连接数为 4*1024=4096 个
 

如果您需要转载,可以点击下方按钮可以进行复制粘贴;本站博客文章为原创,请转载时注明以下信息

张柏沛IT技术博客 > Nginx架构篇之 Nginx和Apache的比较 (七)

热门推荐
推荐新闻