Nginx 限制除了注意操作系统的限制， 现在我来深入到Nginx本身，看看一些指令和方法，我们可以用它来调整Nginx。
Worker Processes(用英文会更好一些)worker_process 是Nginx的主干， 一旦主进程绑定到指定的IP和端口，就会使用nginx指定的用户孵化出子进程， 之后他们会处理所有的工作。 Workers 不是多线程的， 所以不能扩展它超过CPU的核数。 所以我们应该理解设置多个(>1)workers的原理， 通常一个CPU核对应一个worker。 过犹不及，2-4个workers会伤害CPU， 在CPU成为问题之前Nginx会遇到其他的瓶颈。而通常你只是看到了空闲的进程。(这段翻的太烂了希望大家多多改进)
当你正在处理下面这种情况， 你有很多的阻塞(blocking)磁盘IO，这是你可以适当增加worker_process的值。 你需要针您的配置进行测试，检查静态文件的等待时间(waiting time)， 如果值比较大，可以适当的增加worker_process。(这段翻译完有想哭的感觉)
Worker Connectionsworker_connections 是个稍稍有点怪的概念。 我不是很了解这个指令的目的， 但是它有效的限制了在同一时间内每个worker可以维护的连接数。 如果我没猜错的话， 这个配置是为了确保在keep-alive配置不正确的情况下， 当你使用的端口将要耗尽之时，增加连接数。(这个翻译的好难不知道是否正确因为作者也是forced to guess 我也只能被逼去猜了望指正)
默认的值是1024。 我们假设一个李兰奇一般情况下打开2个连接来通过管道获取网站资源，也就是最多可以同时处理512个用户的请求。听起来实在是太少了，但是我们在想一下默认的keepalive-timeout是65(在默认配置文件里面提供了65这个值， 如果没有设置该值，默认值是75，请参考wiki keepalive_timeout)，也就是说我们实际上每秒只能处理8个连接。 显然这个值高于许多人期望的(我没觉得高呵呵)， 尤其是考虑到我们通常会设置2-4个workers。 但是对于流量较大的网站 使用keep-alive是值得的。(翻译完了又想哭了)
此外，我们还必须考虑反向代理， 这将打开一个额外的连接到后台，但是，自Nginx的不支持持久连接到后台，这不是太大的问题，除非你有长时间运行的后台进程。
所有关于worker连接的配置应该是相当清楚的，如果你流量增加了，你要相应的增加worker连接的数量。 2048对于大多数人来说应该是满足了，但老实说，如果你的流量增长了，那么对于workers的数量值应该是多少应该是很清楚的。