前言

nginx安装后一般都会进行参数优化，网上找找也有很多相关文章，但是这些参数优化对Nginx性能会有多大影响？为此我做个简单的实验测试下这些参数能提升多少性能。

声明一下，测试流程比较简单，后端服务也很简单，测试时间也很短，所以实验并不严谨，结果仅作参考，需要根据实际情况进行参数调优。

文章或有错误和疏漏之处，欢迎各位大佬指出或补充。

环境

IP操作系统CPU内存部署服务192.168.3.60Debian 11.844 GBwrk192.168.3.61Debian 11.844 GBnginx192.168.3.62Debian 11.844 GB后端服务

• nginx：版本1.24.0，编译参数：

./configure --with-threads --with-file-aio --with-http_ssl_module --with-http_v2_module --with-http_gunzip_module --with-http_gzip_static_module --with-stream --with-compat --with-pcre-jit --prefix=/home/admin/apps/nginx

• 使用wrk进行性能测试，版本为 4.1.0，通过 apt 包管理器安装。
• 因为主要测试nginx反向代理的性能，所以用go写了个响应"hello world"的api，减少后端服务导致的性能影响。

测试方法：调整nginx参数后多次运行wrk，取平均值。（方法并不严谨，应该用更专业的工具测试运行几小时，将测试数据采用更科学的方法汇总，但时间精力有限，所以采用这个非常简单无脑的实验方法）

实验结果

下面的实验过程主要就是调参数，比较繁琐，所以把实验结果先放到前面。综合配置可参考“实验过程 - 13. 综合调优”。

再次声明，由于测试流程和后端逻辑都比较简单，服务器和网络情况也没严格控制变量所以结果仅供参考。

根据实验结果来看，增大工作进程数能直接提升性能，但不是和CPU核心数一致就能最大化，可能少一点才能达到最佳性能。

除了nginx和系统参数调优，网络和后端服务对性能的影响也很大，而且在大部分ToB业务场景下，后端服务和数据库才是性能短板。

序号测试方式Nginx参数优化项总请求数平均每秒请求数平均延迟优化效果1wrk -> 后端无413998468884.591.66ms+673%2wrk -> nginx -> 后端无，默认配置5348598911.3012.04ms-3.1wrk -> nginx -> 后端设置工作进程数为2102774517127.495.95ms+92.19%3.2wrk -> nginx -> 后端设置工作进程数为367665111274.058.97ms+26.51%3.3wrk -> nginx -> 后端设置工作进程数为auto（4）5477949125.6611.14ms+2.41%4wrk -> nginx -> 后端设置工作进程数和CPU亲和性为auto5377138958.1011.67ms+0.52%5wrk -> nginx -> 后端在4的基础上设置worker_connections 65535;5327588874.8511.80ms-0.4%6wrk -> nginx -> 后端在5的基础上设置accept_mutex on;4255407088.3915.58ms-20.45%7wrk -> nginx -> 后端在6的基础上设置multi_accept on5915009854.7710.60ms+10.58%8wrk -> nginx -> 后端在7的基础上设置改为upstream5586799308.3012.00ms+4.45%9wrk -> nginx -> 后端在8的基础上设置keepalive63267310541.4910.06ms+18.29%10wrk -> nginx -> 后端在9的基础上设置加一个后端100648516772.086.53ms+88.21%11wrk -> nginx -> 后端在2的基础上设置加一个后端61088210178.2610.21ms+14.21%12wrk -> nginx -> 后端在3.1的基础上设置keepalive104102417348.365.94ms+94.67%13wrk -> nginx -> 后端在2的基础上设置deferred5961979934.6110.90ms+11.48%14wrk -> nginx -> 后端在2的基础上修改内核参数5815359689.9110.95ms+8.73%15wrk -> nginx -> 后端综合调优108715118115.785.94ms+103.28%

单独测试nginx的性能，避免后端服务和网络情况的影响。

序号Nginx参数优化项总请求数平均每秒请求数平均延迟优化效果1无，默认配置232740038787.612.71ms-2在1的基础上设置工作进程数为auto7418729123633.13791.04us218.74%3在2的基础上设置CPU亲和性7437087123945.45784.02us219.54%4在3的基础上设置工作进程连接数和多请求7638947127300.44764.67us228.19%

调整环境，nginx都采用默认配置，只是修改了各组件的位置。因为组件在同一台服务器，资源竞争情况也会影响性能。

环境总请求数平均每秒请求数平均延迟wrk、nginx和后端各在不同的服务器5348598911.3012.04mswrk单独服务器，nginx和后端在同一台服务器3866306441.0516.24mswrk、nginx和后端在同一台服务器4021636700.3815.15ms

实验过程

1. 直连后端测试

首先用wrk直接测试后端。因为没有中间商赚差价，所以理论上直连性能会比nginx代理的性能高。

# curl 测试后端响应是否正常
curl http://192.168.3.62:8101# wrk 直接测试后端服务。线程数为4，连接数为100，测试时间为60秒。
wrk -t4 -c100 -d60s http://192.168.3.62:8101

wrk测试结果

总请求数平均每秒请求数平均延迟413998468884.591.66ms

2. 使用nginx默认配置代理

nginx刚安装后有一个默认配置，这里只改了location /的配置，修改为反向代理到后端服务

location / {#root   html;#index  index.html index.htm;proxy_pass http://192.168.3.62:8101;
}

wrk测试结果。相较于后端直连，性能缩水很多

总请求数平均每秒请求数平均延迟5348598911.3012.04ms

3. 增加工作进程数

nginx默认工作进程数为1，通过修改worker_processes可指定，一般小于或等于CPU核心数

worker_processes总请求数平均每秒请求数平均延迟对比默认配置1（默认）5348598911.3012.04ms-2102774517127.495.95ms+92.19%367665111274.058.97ms+26.51%auto（4）5477949125.6611.14ms+2.41%

4. 设置CPU亲和性

通过worker_cpu_affinity绑定工作进程和CPU，避免nginx进程在CPU之间切换导致的伪共享带来的性能问题。

nginx配置：

worker_processes  auto;
worker_cpu_affinity auto;

wrk测试结果

总请求数平均每秒请求数平均延迟对比默认配置5377138958.1011.67ms+0.52%

5. 设置worker_connections

worker_connections用于设置每个Nginx进程可处理并发连接的最大数，默认为1024。

worker_processes  auto;
worker_cpu_affinity auto;
events {worker_connections 65535;
}

wrk测试结果

总请求数平均每秒请求数平均延迟对比默认配置5327588874.8511.80ms-0.4%

6. 启用互斥锁

nginx配置

worker_processes  auto;
worker_cpu_affinity auto;
events {worker_connections 65535;accept_mutex on;
}

wrk测试结果

总请求数平均每秒请求数平均延迟对比默认配置4255407088.3915.58ms-20.45%

7. 启用多请求支持

默认情况下，每个工作进程一次只接受一个新连接。开启后，每个工作进程将接受所有的新连接。

nginx配置

worker_processes  auto;
worker_cpu_affinity auto;
events {worker_connections 65535;accept_mutex on;multi_accept on;
}

wrk测试结果

总请求数平均每秒请求数平均延迟对比默认配置5915009854.7710.60ms+10.58%

8. 使用upstream

之前的配置都通过proxy_pass直接反向代理到后端，修改为upstream。

nginx配置

worker_processes  auto;
worker_cpu_affinity auto;
events {worker_connections 65535;accept_mutex on;multi_accept on;
}
http {upstream backend {server 192.168.3.62:8101;}server {location / {proxy_pass http://backend;}}
}

wrk测试结果。性能有所降低，但在多个后端的情况下，还是配置upstream更方便。

总请求数平均每秒请求数平均延迟对比默认配置5586799308.3012.00ms+4.45%

9. 设置keepalive长连接

长连接的存在可以减少建立和关闭TCP连接带来的消耗和延迟。

nginx配置

worker_processes  auto;
worker_cpu_affinity auto;
events {worker_connections 65535;accept_mutex on;multi_accept on;
}
http {upstream backend {server 192.168.3.62:8101;keepalive 32;keepalive_requests 2000;}server {location / {proxy_pass http://backend;}}
}

wrk测试结果

总请求数平均每秒请求数平均延迟对比默认配置63267310541.4910.06ms+18.29%

10. 增加后端实例数

分别在默认配置和上一步的基础上，将后端实例数加1。

修改后的nginx配置

worker_processes  auto;
worker_cpu_affinity auto;
events {worker_connections 65535;accept_mutex on;multi_accept on;
}
http {upstream backend {server 192.168.3.62:8101;server 192.168.3.62:8102;keepalive 32;keepalive_requests 2000;}server {location / {proxy_pass http://backend;}}
}

wrk测试结果

配置总请求数平均每秒请求数平均延迟对比默认配置默认配置多后端61088210178.2610.21ms+14.21%默认配置，长连接，工作进程数2104102417348.365.94ms+94.67%修改配置多后端100648516772.086.53ms+88.21%

11. 延迟处理新连接

设置deferred参数可延迟处理新连接，加上这个配置后，当用户与nginx服务器建立连接时，只有用户有请求数据时才会将TCP连接状态改为ESTABLISHED，否则就直接丢弃这条连接。通过减少服务器和客户端之间发生的三次握手建立连接的数量来帮助提高性能。

nginx配置

worker_processes  1;
events {worker_connections 1024;
}
http {server {listen 8100 deferred;}
}

wrk测试结果

总请求数平均每秒请求数平均延迟对比默认配置5961979934.6110.90ms+11.48%

12. 修改内核参数

修改的内核参数如下

# 网卡接受数据包的队列最大长度
net.core.netdev_max_backlog = 24800
# 已经收到syn包，但是还没有来得及确认的连接队列
net.ipv4.tcp_max_syn_backlog = 24800
# 端口监听队列的最大长度, 存放的是已经处于ESTABLISHED而没有被应用程序接管的TCP连接
net.core.somaxconn = 65535
# SYN的超时重传次数
net.ipv4.tcp_syn_retries = 2
# 服务端等待客户端响应ACK的超时重传次数
net.ipv4.tcp_synack_retries = 2
# 作为服务端才拥有TCP Fast Open机制
net.ipv4.tcp_fastopen = 2

nginx的配置为默认配置。

wrk测试结果

总请求数平均每秒请求数平均延迟对比默认配置5815359689.9110.95ms+8.73%

13. 综合调优

开启多请求支持，增加工作进程连接数，配置长连接，增加后端实例，修改内核参数。

如果不想一遍遍修改工作进程数，直接设置为auto最省事，虽然不一定会是最优配置，但总比默认强。

nginx配置

worker_processes  auto;
events {worker_connections 65535;multi_accept on;
}
http {upstream backend {server 192.168.3.62:8101;server 192.168.3.62:8102;keepalive 32;keepalive_requests 2000;}server {lister deferred backlog=24800;location / {proxy_pass http://backend;}}
}

内核参数

net.core.netdev_max_backlog = 24800
net.ipv4.tcp_max_syn_backlog = 24800
net.core.somaxconn = 65535
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_fastopen = 2

wrk测试结果

总请求数平均每秒请求数平均延迟对比默认配置108715118115.785.94ms+103.28%

14. 单独测试nginx

以上测试场景都有nginx反向代理后端，而网络和后端也会在一定程度上影响nginx性能，所以这里单独测试nginx。

nginx配置

worker_processes  auto;
worker_cpu_affinity auto;
events {worker_connections 65535;multi_accept on;
}
http {server {location / {return 200 'hello world';}}
}

wrk测试结果。在没有反向代理的情况下，增加工作进程数就能直接提升nginx性能。

序号Nginx参数优化项总请求数平均每秒请求数平均延迟优化效果1无，默认配置232740038787.612.71ms-2在1的基础上设置工作进程数为auto7418729123633.13791.04us218.74%3在2的基础上设置CPU亲和性7437087123945.45784.02us219.54%4在3的基础上设置工作进程连接数和多请求7638947127300.44764.67us228.19%