Nginx服务器中的Socket切分是什么

本篇内容介绍了“Nginx服务器中的Socket切分是什么”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

nginx发布的1.9.1版本引入了一个新的特性：允许使用so_reuseport套接字选项，该选项在许多操作系统的新版本中是可用的，包括dragonfly bsd和linux（内核版本3.9及以后）。该套接字选项允许多个套接字监听同一ip和端口的组合。内核能够在这些套接字中对传入的连接进行负载均衡。（对于nginx plus客户，此功能将在年底发布的版本7中出现）

so_reuseport选项有许多潜在的实际应用。其他服务也可以使用它来简单实现执行中的滚动升级（nginx已经通过支持了滚动升级）。对于nginx而言，启用该选项可以减少在某些场景下的锁竞争而改善性能。

如下图描述，当so_reuseport选项有效时，一个单独的监听socket通知工作进程接入的连接，并且每个工作线程都试图获得连接。

当so_reuseport选项启用是，存在对每一个ip地址和端口绑定连接的多个socket监听器，每一个工作进程都可以分配一个。系统内核决定哪一个有效的socket监听器（通过隐式的方式，给哪一个工作进程）获得连接。这可以减少工作进程之间获得新连接时的封锁竞争（译者注：工作进程请求获得互斥资源加锁之间的竞争），同时在多核系统可以提高性能。然而，这也意味着当一个工作进程陷入阻塞操作时，阻塞影响的不仅是已经接受连接的工作进程，也同时让内核发送连接请求计划分配的工作进程因此变为阻塞。

 设置共享socket

为了让so_reuseport socket选项起作用，应为http或tcp（流模式）通信选项内的listen项直接引入新近的reuseport参数，就像下例这样：
 

复制代码 代码如下:

http {
     server {          listen 80 reuseport;
          server_name  localhost;
          ...
     }
}
 
stream {
     server {          listen 12345 reuseport;
          ...
     }
}

引用reuseport参数后，对引用的socket，accept_mutex参数将会无效，因为互斥量（mutex）对reuseport来说是多余的。对没有使用reuseport的端口，设置accept_mutex仍然是有价值的。

reuseport的基准性能测试

我在一个36核的aws实例运行基准测试工具测试4个nginx 工作进程.为了减少网络的影响，客户端和nginx都运行在本地，并且让nginx返回ok字符串而不是一个文件。我比较三种nginx配置：默认（等同于accept_mutex on ）,accept_mutex off,和reuseport。如图所示，reuseport的每秒请求是其余的两到三倍，同时延迟和延迟标准差也是减少的。

 我又运行了另一个相关的性能测试——客户端和nginx分别在不同的机器上且nginx返回一个html文件。如下表所示，用 reuseport 减少的延迟和之前的性能测试相似，延迟的标准差减少的更为显著（接近十分之一）。其他结果（没有显示在表格中）同样令人振奋。使用 reuseport ，负载被均匀分离到了worker进程。在默认条件下（等同于 accept_mutex on），一些worker分到了较高百分比的负载，而用 accept_mutex off 所有worker都受到了较高的负载。

复制代码 代码如下:

latency (ms)  latency stdev (ms)  cpu load
default  15.65  26.59  0.3
accept_mutex off  15.59  26.48  10
reuseport  12.35  3.15  0.3

在这些性能测试中，连接请求的速度是很高的，但是请求不需要大量的处理。其他的基本的测试应该指出——当应用流量符合这种场景时 reuseport 也能大幅提高性能。（reuseport 参数在 mail 上下文环境下不能用在 listen 指令下，例如email，因为email流量一定不会匹配这种场景。）我们鼓励你先测试而不是直接大规模应用。

“Nginx服务器中的Socket切分是什么”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！