NGINX应用性能优化指南(第二部分)...

来源:InfoQ 作者: 谢丽
  

全标题 NGINX应用性能优化指南(第二部分):反向代理缓冲

【编者的话】本文是“NGINX应用性能优化指南”系列文章的第二篇,主要介绍了如何通过反向代理缓冲实现NGINX应用性能优化。

注:本文最初发布于MaxCDN博客,InfoQ中文站在获得作者授权的基础上对文章进行了翻译。

正文

当NGINX从后台接收响应时,代理缓冲非常有用。这既可以发生在第一次获取可缓冲的资源时,也可以发生在请求动态/不可缓冲内容时。

按照设计,NGINX会为大小合理的响应正文设置缓冲区。但是,如果来自后台应用服务器的响应无法放入这些缓冲区,响应就会被写进一个临时文件。

对于可缓存内容,这不算什么问题,因为你可以恰当地配置缓存,让它基于反向代理的文件系统。然而为了正确设置代理缓冲区的大小,你会想分析应用的不可缓存响应,而对于块编码的响应,你会想分析块与块之间的差别。

指令proxy_buffering决定NGINX是异步(默认启用)还是同步(禁用)转发响应。

 

proxy_buffering禁用时,从服务器收到的数据会被NGINX立即转发,这样可以获得最小的首字节时间(TTFB)。

从响应中读取的数据量受proxy_buffer_size控制——代理缓冲禁用时唯一相关的代理缓冲指令。因此,如果你的目标是TTFB,那么请确保tcp_nodelay被启用(默认),而tcp_nopush被禁用(默认)。

警告:禁用代理缓冲实际上风险相当大,因此,除非你知道自己究竟在做什么,否则我不建议你那么做。通常,反向代理和后台应用服务器位于同一个速度非常快的局域网上。但是客户端连接质量差异巨大,有时还会失速。

如果代理的客户端连接对代理的上游连接(大资源或HTTP/2)造成反压,它就劫持了应用服务器,迫使它以客户端的低速度传送完响应末尾部分。有些人喜欢部署许多性能较差的后台服务器,而这些服务器无法支撑几百个以上的并发连接,对他们而言,这个问题尤为严重。

另一方面,proxy_buffering启用时,要提防使用的代理缓冲区太大。这可能会吃掉你的内存,限制代理能够支持的最大并发连接数。

虽然可能大多数人会配置全局代理缓冲和缓冲区大小,但值得注意的是,这套指令可以针对每个服务器块甚至是每个位置块进行配置,为自定义内容分发提供无限的灵活性。

相关教程:NGINX代理指令清单

 

对于HTML或JavaScript,HTTP Archive的统计表明,单个响应的平均大小小于32KB,因此,你可能不需要调整proxy_buffers的默认值。

在进行无知的猜测前,先看下应用程序响应正文的大小,并设法限制代理缓冲区随动态响应增长,因为那些响应不会被缓存。而且,可缓存响应无论如何都需要存入磁盘,因此设法将它们全部缓冲可能没什么用。

NGINX还能够让应用程序服务器使用HTTP响应头字段X-Accel-Buffering(设置为yesno)根据每个响应决定代理缓冲区行为。不过,它不允许应用服务器影响那个响应的缓冲区大小,因此会使用内在的配置值。或者,就像忽略其他任何带有proxy_ignore_headers指令的HTTP头一样忽略它。

查看引文原文:NGINX Application Performance Optimization:Reverse Proxy Buffering


时间:2016-05-06 08:42 来源:InfoQ 作者: 谢丽 原文链接

好文,顶一下
(0)
0%
文章真差,踩一下
(0)
0%
------分隔线----------------------------


把开源带在你的身边-精美linux小纪念品
无觅相关文章插件,快速提升流量