nginx最大并发连接数的思考：worker_processes、worker_connections、worker_rlimit_nofile

无论是看过的nginx有关书还是网上看到的有关nginx 配置说明的文章（http://wiki.nginx.org/EventsModule#worker_connections），无一例外，在讲到 worker_connections 和 max_clients这两个概念的关系时都一致的一笔带过，尤其是在讲到nginx作为反向代理时max_clients的计算时，都是想当然的贴出max_clients = worker_processes * worker_connections/4这个理论计算公式来。既然是理论公式，那么为什么要除以4呢？肯定是有原因的吧。我相信有些人是知道如何计算的，但是很多人都如我一样一眼扫过，真正等到别人或者自己问自己的时候就真的感觉是云里雾里，不知所以然了

nginx作为http服务器的时候：

max_clients = worker_processes * worker_connections

nginx作为反向代理服务器的时候：

max_clients = worker_processes * worker_connections/4

原因（为什么要除以4）

要弄明白这个问题，先搞清楚worker_processes和worker_connections的官方详细含义

worker_processes：官方英文版wiki配置说明中的描述如下，个人理解为worker角色的进程个数（nginx启动后有多少个worker处理http请求。master不处理请求，而是根据相应配置文件信息管理worker进程. master进程主要负责对外揽活（即接收客户端的请求），并将活儿合理的分配给多个worker，每个worker进程主要负责干活（处理请求））。

syntax:worker_processes number | auto;

default:

worker_processes 1;

context:main

Defines the number of worker processes.

The optimal value depends on many factors including (but not limited to) the number of CPU cores, the number of hard disk drives that store data, and load pattern. When one is in doubt, setting it to the number of available CPU cores would be a good start (the value “auto” will try to autodetect it).

The auto parameter is supported starting from versions 1.3.8 and 1.2.5.

最理想的worker_processes值取决于很多因素，包含但不限于CPU的核数，存储数据的硬盘驱动器个数（跟这个有什么关系？难道和cpu一样，存在跨区域读取数据问题），以及负载模式（？这个是什么？）当其中任何一个因素不确定的时候，将其设置为cpu核数或许是一个比较好的初始值，“自动”也基本是如此确认一个参数值的。

“自动”这个参数值是从nginx 1.3.8和nginx 1.2.5 开始进行支持的，自动参数可以自动检测 cpu cores 并设置 worker_processes 参数 。

在网上也看到以下建议：

nginx doesn’t benefit from more than one worker per CPU.

一个cpu配置多于一个worker数，对nginx而言没有任何益处。

If Nginx is doing CPU-intensive work such as SSL or gzipping and you have 2 or more CPUs/cores, then you may set worker_processes to be equal to the number of CPUs or cores.

如果nginx处理的是cpu密集型（比较耗费cpu的）的操作，建议将此值设置为cpu个数或cpu的核数。

worker_connections：官方解释如下，个人认为是每一个worker进程能并发处理（发起）的最大连接数（包含所有连接数）。

syntax:worker_connections number;

default:

worker_connections 512;

context:events

Sets the maximum number of simultaneous（并发） connections that can be opened by a worker process.

It should be kept in mind（谨记） that this number includes all connections (e.g. connections with proxied servers（与被代理服务之间的连接数）, among others（与其他角色之间的）), not only connections with clients（不仅仅是与客户端之间的连接数）. Another consideration is that the actual（实际的） number of simultaneous connections cannot exceed（超过） the current limit（当前限制） on the maximum number of open files（最大文件打开数）, which can be changed by worker_rlimit_nofile （可以在worker_rlimit_nofile中改变的参数）.

worker_rlimit_nofile xxxxx;

context:events

Specifies（指定） the value for maximum file descriptors（可被一个工作进程打开的最大文件描述符数量） that can be opened by this process.

注意：设置了这个后，修改worker_connections值时，是不能超过worker_rlimit_nofile的这个值。

max_clients：这个参数没有出现在nginx的配置文件中，我也没在官方的文档中找到这个参数，但是很多的文章和书籍都提到了这个参数。有很多人将这个翻译为最大访问客户数，个人认为没有什么不妥的，因此我们就当这个是nginx在理论情况下能处理的最大访问客户数，当然这个客户数不是具体的用户。

当nginx作为http 静态内容的web服务器时，只需要处理来自客户端的连接请求即可（请求是双向的，连接是没有方向的，所以我上面说的反向代理是连接双向，除以4的说法是不正确的）。

由HTTP客户端发起一个请求，创建一个到服务器指定端口（默认是80端口）的TCP连接。HTTP服务器则在那个端口监听客户端的请求。一旦收到请求，服务器会向客户端返回一个状态，比如”HTTP/1.1 200 OK”，以及返回的内容，如请求的文件、错误消息、或者其它信息。同一时刻nginx在处理客户端发送的http请求应该只是一个connection，由此可知理论上作为http web服务器角色的nginx能够处理的最大连接数就是最大客户端连接数。

因此理论上的最大客户端连接数计算公式为：

max_clients = worker_processes * worker_connections;

那一直让我犯迷糊的问题，nginx作为反向代理时可以处理的最大客户连接数是如何计算的呢？

如果只是简单的按照http server服务器的计算模式，加上nginx将用户请求转向被代理服务器时建立的连接，最大的客户连接数也应该还是我之前理解的，在nginx作为http服务器的最大客户端连接数的基础上除以2了。当然，事实上极可能和我想象的不一样了。

官方wiki（页面标记已经过时，但是网上很多文章都在引用）看到一个关于为什么除以4的解释：

如果作为反向代理，因为浏览器默认会开启2个连接到server，而且Nginx还会使用fds（file descriptor）从同一个连接池建立连接到upstream后端。则最大连接数的计算公式如下：

max_clients = worker_processes * worker_connections / 4;

Since（因为） a browser opens 2 connections by default to a server and nginx uses the fds (file descriptors) from the same pool to connect to the upstream backend。