CPU 亲和力设置CPU的亲和力，基本上意味着你告诉每个程序使用的CPU核心，而他们将只使用这个CPU核心。关于这一条，我不想说很多，但你要知道，如果你准备这样做，则必须非常小心。 要知道，你操作系统的 CPU 调度器处理负载均衡的能力要远远超过你。当然，如果你认为你的 CPU 负载均衡有问题，在调度层面上优化它，可能的话找一个替代的调度器。除非你知道你在做什么，否则不要碰这个。
Keep Alivekeep_alive 是 HTTP的一个特性， 它允许客户端维护与服务器已经创建的连接进行一批请求的处理直到指定的超时时间到达。 这个实际上不会在很大程度上改变我们的Nginxserver的性能， 因为Nginx能够很好的处理空闲的连接。 Nginx的作者声称10，000个空闲的连接智慧使用2。5兆内存(unbelievable)， 我个人的使用来说这个值也是靠谱的。
我在这篇性能文章里面提到这个原因非常简单。 对于最终用户来说keep alive对加载时间有着巨大的影响。 这是最重要的指标之一也是我们不断优化的原因。如果你的网站对用户来说感觉加载起来很快，他们就会很开心。 Amazon和一些其他的大型在线零售商做过许多类似的研究表明， 网站的加载时间和网站订单的完成有着直接的关系。
为什么keep alive有着如此巨大的影响， 应该是显而易见的， 那就是你避免为所有的HTTP请求创建各自的连接， 这是非常低效的。 也许你不需要把keepalive-timeout设置为65， 但是10-20应该是比较通用的选择，正如上面一段所说， Nginx会很好的处理这方面。
tcp_nodelay 和 tcp_nopush这两个指令也许是最难理解的nginx配置， 他们对于nginx的影响在网络的较低层。 你可以简单的认为这些指令决定了操作系统如何处理网络缓存和他们何时将这些缓存输出到最终用户(客户端)。 我只能建议大家如果你之前不了解这些概念你最好不要动它。 他们不会显著的改善或者改变性能， 所以最好使用他们的默认值。
硬件限制因为我们要处理nginx带来的所有可能的限制， 所以我们现在需要弄清楚如何有效的利用我们的服务器。为了做到这点我们需要看一下硬件层面的东西，由于大部分服务器瓶颈都会发生在这里。
一般服务器主要还有3个方面的瓶颈。 CPU，内存和IO。 Nginx在CPU的利用方面是非常高效的， 所以我会坦白的告诉你这不会成为瓶颈。 同样nginx在使用内存方面也是很高效的，这也不会成为瓶颈。 现在只剩下IO这个服务器瓶颈的罪魁祸首了。(搞得像找罪犯一样)
如果你经常使用服务器，那么你可能经历过这样认识。硬盘驱动器是真的，真的很慢。从硬盘驱动器读取可能是对服务器最昂贵的操作。 所以自然得出的结论是，为了避免IO瓶颈， 我们需要大量的减少nginx对硬盘驱动器的读写。
要做到这一点，我们可以通过修改Nginx的行为，以减少磁盘写操作，以及确保对nginx的内存限制，允许它避免磁盘访问。
Access Logs
默认情况下，Nginx的每个请求都会记录在磁盘上的日志文件中，你可以使用这个方法进行统计，安全问题检查等， 带着这会在一定程度上带来IO使用成本。 如果你不打算用这些访问日志来做一些检查或其他用途， 你可以直接关闭它以避免对磁盘写操作， 但是如果你需要访问日志，你可以考虑保存日志到内存中。这将会比直接写到磁盘上快很多，并且明显减少IO的使用。
如果你只打算使用访问日志进行统计，你可以考虑使用其他的比如Google analytics来取代(ga和access log还是有区别的 不能简单的取代哦)，或者你只记录访问请求的部分信息而不是全部。
Error Logs
我内心小小的挣扎了一把，我是否要在这里阐述这个error log 指令呢，因为也许你根本不希望关闭error log， 特别是考虑到实际应用中错误日志的量会很少。 但是考虑到这里指令有一个小小的地方需要引起大家注意， 错误日志的等级参数你是可以指定的， 如果你指定的太低了他会记录404错误甚至是debug信息。 在实际的应用中可以将它设置为warn级别，将会是绰绰有余的并且能降低IO。
Open File Cache
从文件系统中读取文件由2部分组成，打开和关闭文件。 考虑到这是一个有阻塞的操作，因此不要忽略这部分。 因此， 对于我们来说缓存打开文件的描述符是非常好的，这就是open_file_cache指令的由来。 链接的wiki地址里对于使用和配置它有着非常好的说明， 所以我建议你去拜读一下。