当前位置: 首页 > 科技观察

面试题:Nginx是如何做到高并发的?常见的优化方法有哪些?

时间:2023-03-21 00:59:34 科技观察

面试题:Nginx是如何实现并发的?为什么Nginx不使用多线程?Nginx常见的优化方式有哪些?502错误的可能原因是什么?面试官的心理分析主要看NGINX的基本原理你是否熟悉,因为大多数运维人员或多或少了解NGINX,但真正了解原理的可能很少。明白了原理才能做优化,否则只能照样照搬,出了问题就无从下手。懂肤浅的人一般都是做WebServer,建网站;初级运维可能会设置HTTPS并配置反向代理;中间运维定义一个upstream,写一个正则判断;老手做性能优化,写个ACL,改源码是可以的(小编说自己没有能力改源码)。面试题解析1.Nginx是如何实现高并发的?异步,非阻塞,使用epoll和大量底层代码优化。如果服务器采用一个进程负责一个请求的方式,那么进程数就是并发数。一般情况下,会有很多进程一直在等待。而nginx采用的是一个master进程,多个woker进程。master进程主要负责收集和分发请求。每当请求到来时,master拉起一个worker进程来处理请求。同时master进程还负责监控woker的状态,保证高可靠性。woker进程一般设置为与CPU核数一致。nginx的woker进程同时处理的请求数只受内存限制,可以同时处理多个请求。Nginx的异步非阻塞工作方式就是利用等待时间。当需要等待的时候,这些进程是空闲的,处于待命状态,所以少量的进程可以解决大量的并发问题。每有一个请求进来,都会有一个worker进程去处理。但不是整个过程,到什么程度?到可能发生阻塞的地步,比如将请求转发到上游(后端)服务器,等待请求返回。然后,加工工人很聪明。发送请求后,他会注册一个事件:“如果上游返回,告诉我,我继续做。”于是他去休息了。这个时候,如果有别的请求进来,他又可以快速的按这种方式处理。一旦upstreamserver返回,就会触发这个事件,worker会接手,请求会继续。2、为什么Nginx不用多线程?Apache:创建多个进程或线程,每个进程或线程会为其分配cpu和内存(线程比进程小很多,所以workers支持比perfork更高的并发),并发过多会消耗服务器资源。Nginx:使用单线程异步非阻塞地处理请求(管理员可以配置Nginx主进程的工作进程数)(epoll),不会为每个请求分配cpu和内存资源,节省大量资源并减少大量CPU上下文切换。这就是Nginx支持更高并发的原因。3、Nginx常见的优化配置有哪些?(1)调整worker_processes为Nginx要产生的worker数量。最佳实践是每个CPU运行一个工作进程。要了解系统的CPU核数,输入$grepprocessor/proc/cpuinfo|wc-l(2)***worker_connectionsNginxWeb服务器可以同时提供服务的客户端数量。与worker_processes结合使用时,获取每秒可以服务的最大客户端数。***客户端/秒=工作进程*工作连接。为了最大限度地发挥Nginx的潜力,workerconnections应该设置为core一次允许运行的***进程数为1024。(3)启用Gzip压缩压缩文件大小,减少传输带宽客户端http,从而提高页面加载速度。推荐的gzip配置示例如下:(在http部分)(4)启用静态文件缓存启用静态文件缓存,减少带宽,提高性能,可以添加如下命令限制电脑的静态文件缓存网页:location~*.(jpg|jpeg|png|gif|ico|css|js)${expires365d;}(5)Timeoutskeepalive连接减少了打开和关闭连接所需的CPU和网络开销。需要调整以获得最佳性能的变量可以参考:(6)禁用access_logs访问日志记录,记录每一个nginx请求,这样会消耗大量的CPU资源,从而降低nginx性能。完全禁用访问日志记录access_logoff;如果您必须具有访问日志记录,请启用访问日志缓冲区access_log/var/log/nginx/access.logmainbuffer=16k4。502错误的可能原因有哪些?(1)FastCGI进程是否已经启动(2)FastCGIworker进程数是否不够(3)FastCGI执行时间过长(4)FastCGIBuffer不够UsingProxying,调整proxy_buffer_size16k;proxy_buffers416k;(6)PHP脚本执行时间过长将php-fpm.conf中的0s0s改为一个时间