我已经谈过一些关于Nginx的常见问题，其中有一些是关于如何优化Nginx，很多Nginx新用户是从Apache迁移过来的，因些他们过去常常调整配置和执行魔术操作来确保服务器高效运行。
我有一些坏消息要告诉你，你不能像Apache一样优化Nginx。它没有魔术配置来减半负载或是让PHP运行速度加快一倍。高兴的是，Nginx已经优化的非常好了，当你决定使用Nginx并用apt-get，yum或是make命令安装的时候它就已经进行了最佳优化。 (注意那些库经常过期，Wiki的安装页面上通常有最新的库)
就是说，很多影响Nginx行为的参数其默认值并不是完全适合高并发的情况。我们也要考虑Nginx运行所在的平台，优化我们的操作系统当有一些限制的时候。
总的来说，我们无法优化单个连接的负载时间，但是我们可以确保Nginx的高并发处理环境。当然， 对于高并发我指的是每秒数百个请求连接，大多数人不需要了解这些。假如你太好奇或是想知道那就继续读吧。
首先，我们需要认识到Nginx几乎可能需要在所有的平台上使用，MacOS，Linux，FreeBSD，Solaris，Windows甚至一些更深奥的系统。他们大部分(这么翻译好些)实现了高性能的基于事件的polling方法，不幸的是Nginx的只支持其中4个系统。在四个系统中我倾向于FreeBSD，但你不会看到太大的性能差异，所以选择的操作系统让你用起来顺手，比选择最优化的操作系统更重要。
我想你一定猜到了windows不在其中。 Windows上的nginx确实没有什么理由让你值得使用。 Windows有自己的一套处理事件polling。 所以nginx的作者选择了不支持。 因此默认的还是使用select() 这种不是很高效而且性能会下降很多的方式。(初次翻译不是很好希望多多指教)
第二个最大的限制， 也是大多数人会遇到的问题是和操作系统相关的。 打开一个Shell窗口， 使用su命令切换到Nginx的运行用户， 运行命令`ulimit -a`。 这些值也会在Nginx在运行中对它进行限制。 在许多操作系统中， "open files"的值是相当有限的， 在我使用的操作系统中， 它的值是 1024。 如果Nginx在运行中操作了这个限制他会记录error log(24： Too many open files) 接着返回一个操作给客户端。 当然Nginx可以处理的文件数可以更大你也可以针对操作系统做一些改动， 你可以放心的去增加这个值。
两种方式可以实现， 你可以通过ulimit设置os的："open files"， 你还可以通过(nginx)配置worker_rlimit_nofile 来申明你期望的值。