我认为，要搞清楚这个公式是否正确，以及如何计算的，那首先要对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 最大文件打开数相关描述