NGINX 1.9.1版中的套接字分片

NGINX | 2015年5月26日

NGINX 1.9.1引入了一项新功能，支持使用SO_REUSEPORT套接字选项。许多操作系统的较新版本均提供此选项，包括DragonFly BSD和Linux（内核版本3.9及更高版本）。此套接字选项允许多个套接字侦听同一IP地址和端口组合。随后，内核会在这些套接字之间对传入连接进行负载均衡。

编者注：对于NGINX Plus用户，NGINX Plus Release 7（R7）及更高版本支持此功能。要概览该版本的所有新功能，请参阅我们博客上的《NGINX Plus R7发布公告》。

The SO_REUSEPORT套接字选项在实际环境中有许多潜在应用。其他服务可以利用该选项轻松实现可执行文件的滚动升级（NGINX已通过其他方式支持滚动升级）。对于NGINX，启用此套接字选项可以减少锁争用，从而在某些场景下提升性能。

如图所示，未启用SO_REUSEPORT选项时，单个侦听套接字会向工作进程通知传入连接，每个工作进程都会尝试接受连接。

启用SO_REUSEPORT选项后，每个IP地址和端口组合都会有多个套接字侦听器，每个工作进程对应一个。内核决定由哪个可用的套接字侦听器（也就是哪个工作进程）接收连接。这有助于减少工作进程接受新连接时的锁争用，并提升多核系统的性能。但这也意味着，当某个工作进程因阻塞操作而停滞时，不仅该进程已接受的连接会受到影响，内核在其阻塞后分配给它的连接请求也会受到影响。

配置套接字分片

要启用SO_REUSEPORT套接字选项，请在用于HTTP或TCP（reuseport参数添加到listen指令中。对于stream模块）流量，示例如下：

http {     server {
          listen 80 reuseport;
          server_name  localhost;
          # ...
     }
}

stream {
     server {
          listen 12345 reuseport;
          # ...
     }
}

添加reuseport参数还会为该套接字禁用accept_mutex指令，因为使用reuseport后互斥锁已无必要。如果某些端口未设置accept_mutex，仍可考虑设置reuseport。

使用`reuseport 进行性能基准测试`

我使用wrk在一台36核AWS实例上对4个NGINX工作进程进行了基准测试。为消除网络影响，我在localhost上同时运行客户端和NGINX，并让NGINX返回字符串OK而不是文件。我比较了三种NGINX配置：默认配置（相当于accept_mutex on）、使用accept_mutex off以及使用reuseport。如图所示，reuseport可将每秒请求数提高到原来的2至3倍，同时降低延迟及延迟的标准差。

我还运行了一项相关的基准测试，其中客户端和NGINX分别位于不同的主机上，并由NGINX返回HTML文件。如下表所示，启用reuseport后，延迟降幅与上一次基准测试相近，而标准差的降幅更为显著（接近10倍）。其他结果（表中未列出）也令人满意。启用reuseport后，负载均匀分布在各个工作进程上。在默认条件下（相当于启用accept_mutex on），部分工作进程承担了更高比例的负载；而在启用accept_mutex off后，所有工作进程都处于高负载状态。

延迟（ms） 延迟标准差（ms） CPU负载默认 15.65 26.59 0.3accept_mutex off 15.59 26.48 10reuseport 12.35 3.15 0.3

在这些基准测试中，连接请求速率很高，但请求不需要大量处理。其他初步测试也表明，当流量符合这一特征时，reuseport对性能的提升最为明显。（例如，reuseport参数不适用于mail上下文中的listen指令，因为电子邮件流量显然不符合这一特征。）建议先测试reuseport，以确定它能否提升NGINX部署的性能，而不要全面应用。有关测试NGINX性能的一些技巧，请参阅nginx.conf 2014上的Konstantin Pavlov演讲。