前言

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

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

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

环境

• 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的性能，避免后端服务和网络情况的影响。

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

实验过程

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测试结果

2. 使用nginx默认配置代理

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

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

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

3. 增加工作进程数

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

4. 设置CPU亲和性

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

nginx配置：

worker_processes  auto;
worker_cpu_affinity auto;

wrk测试结果

5. 设置worker_connections

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

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

wrk测试结果

6. 启用互斥锁

nginx配置

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

wrk测试结果

7. 启用多请求支持

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

nginx配置

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

wrk测试结果

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更方便。

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测试结果

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测试结果

11. 延迟处理新连接

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

nginx配置

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

wrk测试结果

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测试结果

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测试结果

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性能。