nginx中关于并发数的问题worker_connections,worker_processes

我认为，要搞清楚这个公式是否正确，以及如何计算的，那首先要对nginx的各个配置说明有清晰的认识：

从用户的角度，http 1.1协议下，由于浏览器默认使用两个并发连接,因此计算方法：

nginx作为http服务器的时候：

max_clients = worker_processes * worker_connections/2

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

max_clients = worker_processes * worker_connections/4  （

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

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

）

或者从一般建立连接的角度：客户并发连接为1.

nginx作为http服务器的时候：

max_clients = worker_processes * worker_connections

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

max_clients = worker_processes * worker_connections/2

nginx做反向代理时，和客户端之间保持一个连接，和后端服务器保持一个连接。

但是怎样合理的设置worker_processes与worker_connections这两个参数？

worker_processes :

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

最理想的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的核数。

cpu相关信息查看：

　　　　逻辑CPU个数：
   　　　    # cat /proc/cpuinfo | grep "processor" | wc -l

　　　物理CPU个数：
   　　      # cat /proc/cpuinfo | grep "physical id" | sort | uniq | wc -l

　　　  每个物理CPU中Core的个数：
   　　    # cat /proc/cpuinfo | grep "cpu cores" | wc -l

worker_connections：

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

不能超过最大文件打开数：在linux终端中输入ulimit -a进行查看

　　　　　　　　　　　　http://www.jb51.net/LINUXjishu/164573.html  最大文件打开数相关描述