nginx 并发数问题思考：worker_connections,worker_processes与 max clients

我相信，很多人都跟我一样，看书都不会太细致也不太认真思考，感觉书中讲的东西都应该是对的，最近读书时我发现以前认为理所当然的东西事实上压根都没有弄明白，最终的结果是，书是别人的，书中的知识也是别人的。

无论是看过的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的各个配置说明有清晰的认识：

nginx作为http服务器的时候：

max_clients = worker_processes * worker_connections

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

max_clients = worker_processes * worker_connections/4

我们暂且不来判定这两个公式是否正确，我曾经认为nginx作为反向代理，要同时维持客户端和后端被代理server两个链接应该是除以2而不是除以4，后来想到连接请求都是双向的，也就认为除以4应该是正确的。当然，我想的极有可能是不正确的，我的判断是否正确最终还是需要我们根据每一个参数的实际含义来判断（当然，可以很明确的告诉你，我的想法是错误的。至于原因呢，后面告诉你。）。还是让我们一起来看下max_clients，worker_processes和worker_connections的官方说明，对其所包含的含义搞清楚明白，再来确定之间的关系。

worker_processes:

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

1 2 3 4 5

syntax:worker_processes number | auto; default: worker_processes 1; context:main Defines the number of worker processes.

/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf

root     3153     1  0 12:11 ?        00:00:00 nginx: master process

nobody   3154 3153 0 12:11  ?        00:00:00 nginx: worker process               nobody   3155 3153  0 12:11 ?        00:00:00 nginx: worker process

nobody   3156 3153  0 12:11 ?        00:00:00 nginx: worker process

nobody   3157 3153  0 12:11  ?        00:00:00 nginx: worker process

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进程能并发处理（发起）的最大连接数（包含所有连接数）。

1 2 3 4

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后端。则最大连接数的计算公式如下：

1	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。

我有两个疑问：

1. 浏览器怎么知道nginx是作为反向代理的？nginx 响应中会有说明？

2. 如果浏览器知道nginx是作为反向代理的，那为什么需要开启2个连接到server，而且这根使用文件描述符从同一个连接池（这又是什么东东），与后端upstream建立连接有什么关系？

这两个问题解决了，nginx作为反向代理的最大客户连接数的计算也就很明确了。

2014.06.01 0：30分更新：

nginx使用的epoll模型，

作为web server时，在处理http请求时，如果作为web服务器，一个worker进程就可以用来响应一个用户请求。

作为反向代理时，用户发送请求到nginx，nginx发送请求到后端被代理服务器，后端服务器相应给nginx，nginx将内容返回给用户。

由于epoll模型是不等待的，每一步都有可能是由新建连接处理的，但是这也不能说明nginx作为反向代理最大客户连接数是需要除以4的。