Nginx - 软件层面加强Nginx性能优化的面试问答和解决方案
Nginx 软件层面加强Nginx性能优化的面试问答和解决方案
有一次我去爱卡汽车面试PHP,一轮和二轮面的都不错,在三轮面到Nginx的时候很多问题当时不知道怎么回答,确实没有深入学习过,花了一段时间的学习,终于能解答Nginx高性能优化的问题了,10月24号为了获得程序员勋章,发布了半个优化笔记,浏览到了1000+,受到这个鼓舞,我抽时间在仔细整理下关于Nginx性能优化的问题,我们从软件说起。
从软件层面提升硬件使用效率
- 增大CPU的利用率
- 增大内存的利用率
- 增大磁盘I/O的利用率
- 增大网络带宽的利用率
增大CPU的利用率
1、增大Nginx使用CPU的有效时长
- 能够使用全部CPU资源
- master-worker多进程架构
- worker进程数量应当大于等于CPU核数
- Nginx进程间不做无用功浪费CPU资源
- worker进程不应在繁忙时,主动让出CPU
- worker程间不应由于争抢造成资源耗散
- worker进程数量应当等于CPU核数
- worker进程不应调用_些店1导致主动让出CPU
- 拒绝类似的第三方模块
- 不被其他进程争抢资源
- 提升优先级占用CPU更长的时间
- 减少操作系统上耗资源的非Nginx进程
设置worker进程数的技巧和原理:worker进程数量应当大于等于CPU核数,并不是说worker进程数量设置的越大越好,他正确的设置方法应该是CPU核数和CPU核数的倍数,这样在CUP运行时(宏观上并行,微观上串行,把进程的运行时间分为一段段的时间片),这样能最大的利用CPU的资源。
Syntax: worker processes number auto;
Default: worker_processes 1;
Context: main
但不是设置的数值越大就越好,CPU的执行还受到运行时间片的影响,OS调度系统依次选择每个进程,最多执行时间片指定的时长,因为业务、或者是硬盘处理速度的不匹配,阻塞API引发的时间片内主动让出CPU要在减少进程间切换下功夫。
程间切换,就是是指CPU从一个进程或线程切换到另一个进程或线程。查看上下文切换次数的命令有Vmstat
,Dstat
,Pidstat -w
。
设置Priority动态优先级,决定CPU时间片的大小,设置worker进程的静态优先级。
Syntax: worker priority number;
Default: worker_priority 0;
Context: main
CPU依托NUMA架构,我们常说一级缓存,二级缓存,三级缓存,Nginx提高性能的点在于提升CPU缓存命中率,绑定worker到指定CPU。
worker_processes 4;
worker_cpu_affinity 01 10 01 10;
滑动窗口:Nginx在网络传输上的优化
活动窗口功能:用于限制连接的网速,解决报文 舌L序和可靠传输问题,Nginx中limitrate等限速指令皆 依赖它实现,由操作系统内核实现,连接两端各有发送窗口与接收窗。
nginx的超时指令与滑动窗口,主动断开连接,释放网络传输资源。
两次读操作间的超时
Default: client_body_timeout 60s;
Context: http, server, location
两次写操作间的超时
Default: send_timeout 60s;
Context: http, server, location
以上两者兼具:
Default: proxy_timeout 10m;
Context: http, server, location
主动建立连接时应用层超时时间,尽早释放CPU资源。
proxy_connect_timeout 60s;
Context:http, server, location
也不是说Nginx设置的处理链接数越多越好,可能会造成服务器的SYN攻击。当SYN队列满后,新的SYN不进入队列,计算出cookie再以 SYN+ACK中的序列号返回客户端,正常客户端发报文时,服 务器根据报文中携带的cookie重新恢复连接。
net.ipv4.tcp_syncookies = 1
设置worker进程最大连接数量,包括Nginx与上游、下游间的连接。
Syntax: worker_connections_number;
Default: worker_connections 512;
Context: events
Nginx在增大网络带宽的利用率上的优化
当Nginx处理完成调用close关闭连接后,若接收缓冲区仍然收到客户端发来的 内容,则服务器会向客户端发送RST包关闭连接,导致客户端由于收到RST而忽略了http response。
Default: lingering_close on;
Context: http, server, location
当功能启用时,最长的读取用户请求内容的时长,达到后立刻关闭连接。
Default: lingering_time 30s;
Context: http, server, location
当功能启用时,最长的读取用户请求内容的时长,达到后立刻关闭连接。
Default: lingering_timeout 5s;
Context: http, server, location
以RST代替正常的四次握手关闭连接,当其他读、写超时指令生效引发连接关闭时,通过发送RST立刻释放端口、内 存等资源来关闭连接。
Default: reset_timedout_connection off;
Context: http, server, location
TLS/SSL优化握手性能,
ssl_session_cache off | none | [builtin[:size]] [shared:name:size];
Context: http, server
- off 不使用Session缓存,且Nginx在协议中明确告诉客户端Session缓存不被使用
- none 不使用Session缓存
- builtin 使用Openss啲Session缓存,由于在内存中使用,所以仅当同一客户端的两次连接都命中到 同一 worker进程时,Session缓存才会生效
- shared:name:size 定义共享内存,为所有worker进程提供Session缓存服务。IMB大约可用于4000个Session
HTTP长连接,减少握手次数,通过减少并发连接数减少了服务器资源的消耗,降低TCP拥塞控制的影响
Default: keepalive_requests 100;
Context: http, server, location
相关文章
- 第一部分:如何借助当前的自适应比特率技术降低广播延迟 – 定义和测量延迟
- Java if语句
- 使用 Amazon DynamoDB 按需容量模式运行突增工作负载,并将成本降低超过 90%
- 利用信任关系实现同时为两个目录中的用户创建 workspaces 虚拟桌面服务
- S3 成本优化 – Part 2 常见问题以及解决方案
- 在 AWS 中国区方便安全的使用海外公开容器镜像
- 构建无服务化 EFS 文件浏览器
- 保护 EC2 实例的开源工具 – Fail2Ban
- 如何保护 EC2 上元数据以对抗 SSRF 攻击
- python logging 用法
- 使用零终端或瘦终端设备访问 Amazon WorkSpaces
- 如何在 Amazon ElastiCache for Redis 上使用集群模式
- 在 Amazon EKS 集群中使用 Envoy 无缝集成 AWS Lambda
- Amazon EKS 现在支持 EC2 Inf1 实例
- 使用 ezsmdeploy Python 程序包和几行代码将机器学习模型部署到 Amazon SageMaker
- 瞬息万变时代中的扩展挑战
- 使用 AWS CodeArtifact 的软件程序包管理
- 使用 AWS CDK 加速 EKS 集群部署
- VPC 安全的十个最佳实践
- 基于 MediaConvert 实现加载 WebVTT 字幕的 HLS 流媒体的封装