高并发下的Nginx优化

这两个指令也许是最难理解的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地址里对于使用和配置它有着非常好的说明, 所以我建议你去拜读一下.

Buffers

配置Nginx缓存的大小是一个非常重要的事情. 如果缓存大小设置的太小, Nginx将不得不把上游(用英文upsteams会更好)的相应结果存放到临时的缓存文件里面,这将会同时增加IO的读写操作, 而且流量越大问题越多.

client_body_buffer_size指令用来指定处理客户端请求的缓冲区大小, 这个代表了访问请求的body. 这是用来处理POST的数据,也就是通过提交表单,文件上传等请求的数据. 如果你需要处理很多大的POST请求的,你必须确保缓存区要设置的足够大.

fastcgi_buffers 和 proxy_buffers 指令用来处理上流(upstream)的响应结果, 也就是PHP Apache等.它的概念其实和上面提到的差不多, 如果缓冲区不足够大数据将在返回给用户使用之前被保存到磁盘上. 注意Nginx将这个buffer数据同步的传输给客户端之前,有一个缓存上限, 保存到磁盘也同样受限. 这个上线是通过fastcgi_max_temp_file_size和proxy_max_temp_file_size来设置的. 另外对于代理的连接你也可以通过把proxy_buffering设置成off来彻底的关闭缓存.(通常这不是一个好办法). 

彻底移除磁盘IO

最好的减少磁盘IO的方法无疑是不使用磁盘, 如果你的的应用只有少量的数据传输,你可以将数据都放入内存,这样就可以彻底不用考虑磁盘IO的阻塞了. 当然默认情况下你的操作系统也会缓存频繁访问的磁盘扇区, 所以内存越大磁盘的IO就会用到的越少. 这就意味着你可以通过增加内存来解决IO的瓶颈. 数据量越多,需要的内存越大.

网络IO

为了好玩,我们假设你有了足够大的内存来缓存你的所有数据. 这意味着理论上你的IO读速度达到了3-6gbps. 但是你没有那么快的网络通道. 不幸的是,我们可以优化的网络IO是有限的,我们要通过网络传输数据,所以还将受制于网络IO. 唯一真正有效的方法是尽量减少数据量或压缩。

幸运的是Nginx提供了gzip模块, 它可以使我们在将数据传输给客户端之前压缩它, 这将大大减少数据的大小. 一般来说 gzip_comp_level的值不会在性能方面有多大的差别,设为为4-5即可. 一味的增加它是没有意义的只是浪费的CPU的周期. 

你也可以通过一些javascript和css缩小工具来减少传输文件大小. 但这些不是和Nginx很相关所以我相信你通过google可以获取更多的相关信息.

唷~

这篇文章已经临近结尾了。如果你还需要更进一步的优化，是时候考虑一下通过增加服务器了，没有必要继续在微优化 Nginx 上浪费时间，当然，那将是另一个时间的另一篇文章中讨论的话题。如果你因为这篇文章刚好2400个字而好奇（原稿），在进一步探索我的博客前，请小憩一下。

英文链接：Optimizing Nginx for High Traffic Loads

译文链接：http://www.oschina.net/translate/optimizing-nginx-for-high-traffic-loads

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!