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 （設置為 yes 或 no ）根據每個響應決定代理緩沖區行為。不過，它不允許應用服務器影響那個響應的緩沖區大小，因此會使用 內在的 配置值。或者，就像忽略其他任何帶有 proxy_ignore_headers 指令的HTTP頭一樣忽略它。

來自： http://www.infoq.com/cn/articles/nginx-application-performance-part02