Nginx 是如何实现高并发?常见的优化手段有哪些?

简介: Nginx 是如何实现高并发?常见的优化手段有哪些?
  • 这是一位读者带回来的面试题
  • 面试官心理分析
  • 面试题剖析
  • 为什么 Nginx 不使用多线程?
  • Nginx常见的优化配置有哪些?

这是一位读者带回来的面试题

Nginx 是如何实现并发的?为什么 Nginx 不使用多线程?Nginx常见的优化手段有哪些?502错误可能原因有哪些?

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能。

项目地址:https://github.com/YunaiV/ruoyi-vue-pro

面试官心理分析

主要是看应聘人员的对NGINX的基本原理是否熟悉,因为大多数人多多少少都懂点NGINX,但是真正其明白原理的可能少之又少。明白其原理,才能做优化,否则只能照样搬样,出了问题也无从下手。

懂皮毛的人,一般会做个 Web Server,搭建一个 Web 站点;初级运维可能搞个 HTTPS 、配置一个反向代理; 中级运维定义个 upstream、写个正则判断;老鸟做个性能优化、写个ACL,还有可能改改源码(小编表示没有改源码的能力)。

基于微服务的思想,构建在 B2C 电商场景下的项目实战。核心技术栈,是 Spring Boot + Dubbo 。未来,会重构成 Spring Cloud Alibaba 。

项目地址:https://github.com/YunaiV/onemall

面试题剖析

Nginx 是如何实现高并发的?

异步,非阻塞,使用了epoll 和大量的底层代码优化。

如果一个server采用一个进程负责一个request的方式,那么进程数就是并发数。正常情况下,会有很多进程一直在等待中。

而nginx采用一个master进程,多个woker进程的模式。

  • master进程主要负责收集、分发请求。每当一个请求过来时,master就拉起一个worker进程负责处理这个请求。
  • 同时master进程也负责监控woker的状态,保证高可靠性
  • woker进程一般设置为跟cpu核心数一致。nginx的woker进程在同一时间可以处理的请求数只受内存限制,可以处理多个请求。
  • Nginx 的异步非阻塞工作方式正把当中的等待时间利用起来了。在需要等待的时候,这些进程就空闲出来待命了,因此表现为少数几个进程就解决了大量的并发问题。

image.png

每进来一个request,会有一个worker进程去处理。但不是全程的处理,处理到什么程度呢?处理到可能发生阻塞的地方,比如向上游(后端)服务器转发request,并等待请求返回。那么,这个处理的worker很聪明,他会在发送完请求后,注册一个事件:“如果upstream返回了,告诉我一声,我再接着干”。于是他就休息去了。

此时,如果再有request 进来,他就可以很快再按这种方式处理。而一旦上游服务器返回了,就会触发这个事件,worker才会来接手,这个request才会接着往下走。

为什么 Nginx 不使用多线程?

Apache: 创建多个进程或线程,而每个进程或线程都会为其分配 cpu 和内存(线程要比进程小的多,所以worker支持比perfork高的并发),并发过大会耗光服务器资源。

Nginx: 采用单线程来异步非阻塞处理请求(管理员可以配置Nginx主进程的工作进程的数量)(epoll),不会为每个请求分配cpu和内存资源,节省了大量资源,同时也减少了大量的CPU的上下文切换。所以才使得Nginx支持更高的并发。

Nginx常见的优化配置有哪些?

1)调整worker_processes

指Nginx要生成的worker数量,最佳实践是每个CPU运行1个工作进程。

了解系统中的CPU核心数,输入

$ grep processor / proc / cpuinfo | wc -l
2)最大化worker_connections

Nginx Web服务器可以同时提供服务的客户端数。与worker_processes结合使用时,获得每秒可以服务的最大客户端数

最大客户端数/秒=工作进程*工作者连接数

为了最大化Nginx的全部潜力,应将工作者连接设置为核心一次可以运行的允许的最大进程数1024。

3)启用Gzip压缩

压缩文件大小,减少了客户端http的传输带宽,因此提高了页面加载速度

建议的gzip配置示例如下:( 在http部分内)

6.png

图片

4)为静态文件启用缓存

为静态文件启用缓存,以减少带宽并提高性能,可以添加下面的命令,限定计算机缓存网页的静态文件:

location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {  
expires 365d;  
}
5)Timeouts

keepalive连接减少了打开和关闭连接所需的CPU和网络开销,获得最佳性能需要调整的变量可参考:

7.png

6)禁用access_logs

访问日志记录,它记录每个nginx请求,因此消耗了大量CPU资源,从而降低了nginx性能。

完全禁用访问日志记录

access_log off;

如果必须具有访问日志记录,则启用访问日志缓冲

access_log /var/log/nginx/access.log主缓冲区= 16k
502报错可能原因有哪些?

8.png

  • 1)FastCGI进程是否已经启动
  • 2)FastCGI worker进程数是否不够
  • 3)FastCGI执行时间过长
  • 4)FastCGI Buffer不够

nginx和apache一样,有前端缓冲限制,可以调整缓冲参数

fastcgi_buffer_size 32k;    
fastcgi_buffers 8 32k;
  • 5)Proxy Buffer不够

如果你用了Proxying,调整

proxy_buffer_size 16k;    
proxy_buffers 4 16k;
  • 6)php脚本执行时间过长

将php-fpm.conf的<value name="request_terminate_timeout">0s</value>的0s改成一个时间

相关实践学习
通过日志服务实现云资源OSS的安全审计
本实验介绍如何通过日志服务实现云资源OSS的安全审计。
相关文章
|
7月前
|
数据采集 存储 弹性计算
高并发Java爬虫的瓶颈分析与动态线程优化方案
高并发Java爬虫的瓶颈分析与动态线程优化方案
|
8月前
|
运维 监控 Kubernetes
高并发来了,运维别慌:如何优化运维流程,才能稳住阵脚?
高并发来了,运维别慌:如何优化运维流程,才能稳住阵脚?
241 4
|
7月前
|
数据采集 网络协议 API
协程+连接池:高并发Python爬虫的底层优化逻辑
协程+连接池:高并发Python爬虫的底层优化逻辑
|
10月前
|
缓存 监控 Cloud Native
Java Solon v3.2.0 高并发与低内存实战指南之解决方案优化
本文深入解析了Java Solon v3.2.0框架的实战应用,聚焦高并发与低内存消耗场景。通过响应式编程、云原生支持、内存优化等特性,结合API网关、数据库操作及分布式缓存实例,展示其在秒杀系统中的性能优势。文章还提供了Docker部署、监控方案及实际效果数据,助力开发者构建高效稳定的应用系统。代码示例详尽,适合希望提升系统性能的Java开发者参考。
501 4
Java Solon v3.2.0 高并发与低内存实战指南之解决方案优化
|
10月前
|
缓存 NoSQL 算法
高并发秒杀系统实战(Redis+Lua分布式锁防超卖与库存扣减优化)
秒杀系统面临瞬时高并发、资源竞争和数据一致性挑战。传统方案如数据库锁或应用层锁存在性能瓶颈或分布式问题,而基于Redis的分布式锁与Lua脚本原子操作成为高效解决方案。通过Redis的`SETNX`实现分布式锁,结合Lua脚本完成库存扣减,确保操作原子性并大幅提升性能(QPS从120提升至8,200)。此外,分段库存策略、多级限流及服务降级机制进一步优化系统稳定性。最佳实践包括分层防控、黄金扣减法则与容灾设计,强调根据业务特性灵活组合技术手段以应对高并发场景。
2705 7
|
存储 监控 固态存储
在高并发环境下,如何优化 WAL 的写入性能?
在高并发环境下,如何优化 WAL 的写入性能?
291 2
|
负载均衡 前端开发 应用服务中间件
负载均衡指南:Nginx与HAProxy的配置与优化
负载均衡指南:Nginx与HAProxy的配置与优化
884 3
|
缓存 前端开发 JavaScript
nginx的优化
nginx的优化
|
消息中间件 安全 大数据
Kafka多线程Consumer是实现高并发数据处理的有效手段之一
【9月更文挑战第2天】Kafka多线程Consumer是实现高并发数据处理的有效手段之一
1387 5
|
缓存 监控 负载均衡
nginx相关配置及高并发优化
Nginx的高并发优化是一个综合性的过程,需要根据具体的业务场景和硬件资源量身定制。以上配置只是基础,实际应用中还需根据服务器监控数据进行持续调整和优化。例如,利用工具如ab(Apache Benchmarks)进行压力测试,监控CPU、内存、网络和磁盘I/O等资源使用情况,确保配置的有效性和服务的稳定性。
596 0