Nginx 软件层面加强Nginx性能优化的面试问答和解决方案

Nginx 软件层面加强Nginx性能优化的面试问答和解决方案

去年我去爱卡汽车面试PHP，一轮和二轮面的都不错，在三轮面到Nginx的时候很多问题当时不知道怎么回答，确实没有深入学习过，花了一段时间的学习，终于能解答Nginx高性能优化的问题了，10月24号为了获得程序员勋章，发布了半个优化笔记，浏览到了1000+，受到这个鼓舞，我抽时间在仔细整理下关于Nginx性能优化的问题，我们从软件说起。

360网站源码总结：从软件层面提升硬件使用效率

增大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

1

2

3

但不是设置的数值越大就越好，CPU的执行还受到运行时间片的影响，OS调度系统依次选择每个进程，最多执行时间片指定的时长，因为业务、或者是硬盘处理速度的不匹配，阻塞API引发的时间片内主动让出CPU要在减少进程间切换下功夫。

程间切换，就是是指CPU从一个进程或线程切换到另一个进程或线程。查看上下文切换次数的命令有Vmstat,Dstat,Pidstat -w。

设置Priority动态优先级，决定CPU时间片的大小，设置worker进程的静态优先级。

Syntax: worker priority number;

Default: worker_priority 0;

Context: main

1

2

3

CPU依托NUMA架构，我们常说一级缓存，二级缓存，三级缓存，Nginx提高性能的点在于提升CPU缓存命中率，绑定worker到指定CPU。

worker_processes     4;

worker_cpu_affinity 01 10 01 10;

1

2

滑动窗口:Nginx在网络传输上的优化

活动窗口功能：用于限制连接的网速，解决报文 舌L序和可靠传输问题，Nginx中limitrate等限速指令皆 依赖它实现，由操作系统内核实现，连接两端各有发送窗口与接收窗。

nginx的超时指令与滑动窗口，主动断开连接，释放网络传输资源。

两次读操作间的超时

Default: client_body_timeout 60s;

Context: http, server, location

1

2

两次写操作间的超时

Default: send_timeout 60s;

Context: http, server, location

1

2

以上两者兼具:

Default: proxy_timeout 10m;

Context: http, server, location

1

2

主动建立连接时应用层超时时间，尽早释放CPU资源。

proxy_connect_timeout 60s; 

Context:http, server, location

1

2

也不是说Nginx设置的处理链接数越多越好，可能会造成服务器的SYN攻击。当SYN队列满后，新的SYN不进入队列，计算出cookie再以 SYN+ACK中的序列号返回客户端，正常客户端发报文时，服 务器根据报文中携带的cookie重新恢复连接。

net.ipv4.tcp_syncookies = 1

1

设置worker进程最大连接数量，包括Nginx与上游、下游间的连接。

Syntax: worker_connections_number;

Default: worker_connections 512;

Context: events

1

2

3

Nginx在增大网络带宽的利用率上的优化

当Nginx处理完成调用close关闭连接后，若接收缓冲区仍然收到客户端发来的 内容，则服务器会向客户端发送RST包关闭连接,导致客户端由于收到RST而忽略了http response。

Default: lingering_close on;

Context: http, server, location

1

2

当功能启用时，最长的读取用户请求内容的时长，达到后立刻关闭连接。

Default: lingering_time 30s;

Context: http, server, location

1

2

当功能启用时，最长的读取用户请求内容的时长，达到后立刻关闭连接。

Default: lingering_timeout 5s;

Context: http, server, location

1

2

以RST代替正常的四次握手关闭连接,当其他读、写超时指令生效引发连接关闭时，通过发送RST立刻释放端口、内 存等资源来关闭连接。

Default: reset_timedout_connection off;

Context: http, server, location

1

2

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

1

2

3

4

5

6

7

HTTP长连接,减少握手次数,通过减少并发连接数减少了服务器资源的消耗,降低TCP拥塞控制的影响

Default: keepalive_requests 100;

Context: http, server, location

————————————————