前言
nginx安装后一般都会进行参数优化，网上找找也有很多相关文章，但是这些参数优化对Nginx性能会有多大影响？为此我做个简单的实验测试下这些参数能提升多少性能。
声明一下，测试流程比较简单，后端服务也很简单，测试时间也很短，所以实验并不严谨，结果仅作参考，需要根据实际情况进行参数调优。
文章或有错误和疏漏之处，欢迎各位大佬指出或补充。
环境
| IP | 操作系统 | CPU | 内存 | 部署服务 |
|---|---|---|---|---|
| 192.168.3.60 | Debian 11.8 | 4 | 4 GB | wrk |
| 192.168.3.61 | Debian 11.8 | 4 | 4 GB | nginx |
| 192.168.3.62 | Debian 11.8 | 4 | 4 GB | 后端服务 |
- nginx：版本1.24.0，编译参数：
bash
./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参数优化项 | 总请求数 | 平均每秒请求数 | 平均延迟 | 优化效果 |
|---|---|---|---|---|---|---|
| 1 | wrk -> 后端 | 无 | 4139984 | 68884.59 | 1.66ms | +673% |
| 2 | wrk -> nginx -> 后端 | 无，默认配置 | 534859 | 8911.30 | 12.04ms | - |
| 3.1 | wrk -> nginx -> 后端 | 设置工作进程数为2 | 1027745 | 17127.49 | 5.95ms | +92.19% |
| 3.2 | wrk -> nginx -> 后端 | 设置工作进程数为3 | 676651 | 11274.05 | 8.97ms | +26.51% |
| 3.3 | wrk -> nginx -> 后端 | 设置工作进程数为auto（4） | 547794 | 9125.66 | 11.14ms | +2.41% |
| 4 | wrk -> nginx -> 后端 | 设置工作进程数和CPU亲和性为auto | 537713 | 8958.10 | 11.67ms | +0.52% |
| 5 | wrk -> nginx -> 后端 | 在4的基础上设置worker_connections 65535; | 532758 | 8874.85 | 11.80ms | -0.4% |
| 6 | wrk -> nginx -> 后端 | 在5的基础上设置accept_mutex on; | 425540 | 7088.39 | 15.58ms | -20.45% |
| 7 | wrk -> nginx -> 后端 | 在6的基础上设置multi_accept on | 591500 | 9854.77 | 10.60ms | +10.58% |
| 8 | wrk -> nginx -> 后端 | 在7的基础上设置改为upstream | 558679 | 9308.30 | 12.00ms | +4.45% |
| 9 | wrk -> nginx -> 后端 | 在8的基础上设置keepalive | 632673 | 10541.49 | 10.06ms | +18.29% |
| 10 | wrk -> nginx -> 后端 | 在9的基础上设置加一个后端 | 1006485 | 16772.08 | 6.53ms | +88.21% |
| 11 | wrk -> nginx -> 后端 | 在2的基础上设置加一个后端 | 610882 | 10178.26 | 10.21ms | +14.21% |
| 12 | wrk -> nginx -> 后端 | 在3.1的基础上设置keepalive | 1041024 | 17348.36 | 5.94ms | +94.67% |
| 13 | wrk -> nginx -> 后端 | 在2的基础上设置deferred | 596197 | 9934.61 | 10.90ms | +11.48% |
| 14 | wrk -> nginx -> 后端 | 在2的基础上修改内核参数 | 581535 | 9689.91 | 10.95ms | +8.73% |
| 15 | wrk -> nginx -> 后端 | 综合调优 | 1087151 | 18115.78 | 5.94ms | +103.28% |
单独测试nginx的性能，避免后端服务和网络情况的影响。
| 序号 | Nginx参数优化项 | 总请求数 | 平均每秒请求数 | 平均延迟 | 优化效果 |
|---|---|---|---|---|---|
| 1 | 无，默认配置 | 2327400 | 38787.61 | 2.71ms | - |
| 2 | 在1的基础上设置工作进程数为auto | 7418729 | 123633.13 | 791.04us | 218.74% |
| 3 | 在2的基础上设置CPU亲和性 | 7437087 | 123945.45 | 784.02us | 219.54% |
| 4 | 在3的基础上设置工作进程连接数和多请求 | 7638947 | 127300.44 | 764.67us | 228.19% |
调整环境，nginx都采用默认配置，只是修改了各组件的位置。因为组件在同一台服务器，资源竞争情况也会影响性能。
| 环境 | 总请求数 | 平均每秒请求数 | 平均延迟 |
|---|---|---|---|
| wrk、nginx和后端各在不同的服务器 | 534859 | 8911.30 | 12.04ms |
| wrk单独服务器，nginx和后端在同一台服务器 | 386630 | 6441.05 | 16.24ms |
| wrk、nginx和后端在同一台服务器 | 402163 | 6700.38 | 15.15ms |
实验过程
1. 直连后端测试
首先用wrk直接测试后端。因为没有中间商赚差价，所以理论上直连性能会比nginx代理的性能高。
bash
# curl 测试后端响应是否正常
curl http://192.168.3.62:8101
# wrk 直接测试后端服务。线程数为4，连接数为100，测试时间为60秒。
wrk -t4 -c100 -d60s http://192.168.3.62:8101wrk测试结果
| 总请求数 | 平均每秒请求数 | 平均延迟 |
|---|---|---|
| 4139984 | 68884.59 | 1.66ms |
2. 使用nginx默认配置代理
nginx刚安装后有一个默认配置，这里只改了location /的配置，修改为反向代理到后端服务
less
location / {
#root html;
#index index.html index.htm;
proxy_pass http://192.168.3.62:8101;
}wrk测试结果。相较于后端直连，性能缩水很多
| 总请求数 | 平均每秒请求数 | 平均延迟 |
|---|---|---|
| 534859 | 8911.30 | 12.04ms |
3. 增加工作进程数
nginx默认工作进程数为1，通过修改worker_processes可指定，一般小于或等于CPU核心数
| worker_processes | 总请求数 | 平均每秒请求数 | 平均延迟 | 对比默认配置 |
|---|---|---|---|---|
| 1（默认） | 534859 | 8911.30 | 12.04ms | - |
| 2 | 1027745 | 17127.49 | 5.95ms | +92.19% |
| 3 | 676651 | 11274.05 | 8.97ms | +26.51% |
| auto（4） | 547794 | 9125.66 | 11.14ms | +2.41% |
4. 设置CPU亲和性
通过worker_cpu_affinity绑定工作进程和CPU，避免nginx进程在CPU之间切换导致的伪共享带来的性能问题。
nginx配置：
arduino
worker_processes auto;
worker_cpu_affinity auto;wrk测试结果
| 总请求数 | 平均每秒请求数 | 平均延迟 | 对比默认配置 |
|---|---|---|---|
| 537713 | 8958.10 | 11.67ms | +0.52% |
5. 设置worker_connections
worker_connections用于设置每个Nginx进程可处理并发连接的最大数，默认为1024。
ini
worker_processes auto;
worker_cpu_affinity auto;
events {
worker_connections 65535;
}wrk测试结果
| 总请求数 | 平均每秒请求数 | 平均延迟 | 对比默认配置 |
|---|---|---|---|
| 532758 | 8874.85 | 11.80ms | -0.4% |
6. 启用互斥锁
nginx配置
ini
worker_processes auto;
worker_cpu_affinity auto;
events {
worker_connections 65535;
accept_mutex on;
}wrk测试结果
| 总请求数 | 平均每秒请求数 | 平均延迟 | 对比默认配置 |
|---|---|---|---|
| 425540 | 7088.39 | 15.58ms | -20.45% |
7. 启用多请求支持
默认情况下，每个工作进程一次只接受一个新连接。开启后，每个工作进程将接受所有的新连接。
nginx配置
ini
worker_processes auto;
worker_cpu_affinity auto;
events {
worker_connections 65535;
accept_mutex on;
multi_accept on;
}wrk测试结果
| 总请求数 | 平均每秒请求数 | 平均延迟 | 对比默认配置 |
|---|---|---|---|
| 591500 | 9854.77 | 10.60ms | +10.58% |
8. 使用upstream
之前的配置都通过proxy_pass直接反向代理到后端，修改为upstream。
nginx配置
ini
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更方便。
| 总请求数 | 平均每秒请求数 | 平均延迟 | 对比默认配置 |
|---|---|---|---|
| 558679 | 9308.30 | 12.00ms | +4.45% |
9. 设置keepalive长连接
长连接的存在可以减少建立和关闭TCP连接带来的消耗和延迟。
nginx配置
ini
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测试结果
| 总请求数 | 平均每秒请求数 | 平均延迟 | 对比默认配置 |
|---|---|---|---|
| 632673 | 10541.49 | 10.06ms | +18.29% |
10. 增加后端实例数
分别在默认配置和上一步的基础上，将后端实例数加1。
修改后的nginx配置
ini
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测试结果
| 配置 | 总请求数 | 平均每秒请求数 | 平均延迟 | 对比默认配置 |
|---|---|---|---|---|
| 默认配置多后端 | 610882 | 10178.26 | 10.21ms | +14.21% |
| 默认配置，长连接，工作进程数2 | 1041024 | 17348.36 | 5.94ms | +94.67% |
| 修改配置多后端 | 1006485 | 16772.08 | 6.53ms | +88.21% |
11. 延迟处理新连接
设置deferred参数可延迟处理新连接，加上这个配置后，当用户与nginx服务器建立连接时，只有用户有请求数据时才会将TCP连接状态改为ESTABLISHED，否则就直接丢弃这条连接。通过减少服务器和客户端之间发生的三次握手建立连接的数量来帮助提高性能。
nginx配置
ini
worker_processes 1;
events {
worker_connections 1024;
}
http {
server {
listen 8100 deferred;
}
}wrk测试结果
| 总请求数 | 平均每秒请求数 | 平均延迟 | 对比默认配置 |
|---|---|---|---|
| 596197 | 9934.61 | 10.90ms | +11.48% |
12. 修改内核参数
修改的内核参数如下
ini
# 网卡接受数据包的队列最大长度
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 = 2nginx的配置为默认配置。
wrk测试结果
| 总请求数 | 平均每秒请求数 | 平均延迟 | 对比默认配置 |
|---|---|---|---|
| 581535 | 9689.91 | 10.95ms | +8.73% |
13. 综合调优
开启多请求支持，增加工作进程连接数，配置长连接，增加后端实例，修改内核参数。
如果不想一遍遍修改工作进程数，直接设置为auto最省事，虽然不一定会是最优配置，但总比默认强。
nginx配置
ini
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;
}
}
}内核参数
ini
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 = 2wrk测试结果
| 总请求数 | 平均每秒请求数 | 平均延迟 | 对比默认配置 |
|---|---|---|---|
| 1087151 | 18115.78 | 5.94ms | +103.28% |
14. 单独测试nginx
以上测试场景都有nginx反向代理后端，而网络和后端也会在一定程度上影响nginx性能，所以这里单独测试nginx。
nginx配置
ini
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 | 无，默认配置 | 2327400 | 38787.61 | 2.71ms | - |
| 2 | 在1的基础上设置工作进程数为auto | 7418729 | 123633.13 | 791.04us | 218.74% |
| 3 | 在2的基础上设置CPU亲和性 | 7437087 | 123945.45 | 784.02us | 219.54% |
| 4 | 在3的基础上设置工作进程连接数和多请求 | 7638947 | 127300.44 | 764.67us | 228.19% |