转载

NGINX应用性能优化指南（第二部分）：反向代理缓冲

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

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

正文

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

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

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

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

NGINX应用性能优化指南（第二部分）：反向代理缓冲

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

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

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

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

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

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

本站定位：个人技术类博客

本站作用：写博客、记日志、闲聊扯淡鼓捣技术。