NGINX應用性能優化指南（第一部分）：時間消耗分析

【編者的話】本文是“NGINX應用性能優化指南”系列文章的第一篇，主要介紹了如何通過時間消耗分析實現NGINX應用性能優化。

正文

在深入討論細節之前，我們先考慮下從哪里優化以及為什么優化可能讓一個富內容Web應用發生有意義的轉變。

往返時間 （RTT）

RTT是一個最重要的變量，因為它既能影響延遲，又能影響吞吐量。其影響體現在客戶端請求的全部三個階段：初始連接建立時間、請求-響應延遲和響應正文傳送吞吐量。

新建一個HTTPS連接包括DNS查詢（通常小于10毫秒）、TCP握手和TLS隧道協商。一旦HTTPS連接建立，每個請求/響應都會（至少）再需要一個RTT。你數一下就會知道，一個新建連接上的單個HTTPS請求最少需要4個RTT：

注意：如果要發送的數據大于TCP擁塞窗口，那么可能還需要額外的往返。事實上，要發送的大量初始化數據可能對TCP事務的兩個方向均有影響：一方面是客戶端請求大小（比如較大的POST），一方面是服務器TLS認證鏈和服務器響應正文。

最后，不要忘記，TCP吞吐量與RTT是成反比的。其他條件相同的話，RTT加倍則TCP吞吐量減半。為此，我們需要考慮源服務器相對于客戶端的位置。

從美國東海岸到美國西海岸的RTT大約為80毫秒，這是相當可觀的。美國東海岸到亞洲的RTT達到了令人厭煩的程度，取決于所用路由的不同，在150毫秒到400毫秒之間。而且，在出現網絡擁塞時，端點之間的RTT可能會增加（bufferbloat）并大幅抖動（jitter）。

按照O’Reilly出版的《高性能瀏覽器網絡》一書的介紹，如果一個應用程序設計供人使用，那么就必須考慮人的時間感知。因此，我們應該竭力在250毫秒之內提供可視化反饋，以吸引用戶的注意力——既可以是展示靜態內容，開始視頻播放，也可以是確認行動請求。

另一方面，如果你正在使用CDN，而且它有一個接入點（POP）距離你的終端用戶比較近，那么RTT會非常低，大約5到15毫秒。可緩存內容將從CDN邊緣節點中獲取，瀏覽器和移動應用可以在動態內容還在從上游獲取時就開始渲染，提高了用戶感受到的響應性。

相關教程：什么是內容緩存？

為了節省同源服務器建立連接的時間，CDN邊緣節點通常會保持長連接——同瀏覽器使用HTTP/1.1頭Connection: keep-alive保持長連接是一個意思。事實上，部分CDN甚至提供了一種分層的中間節點層次結構，用于提高持久連接的可擴展性和連接故障。MaxCDN使用Origin Shield做這件事。

如果你還沒有使用CDN，那么你就只能受到源服務器的RTT支配。但是，你可以使用與瀏覽器和CDN同樣的技巧來改善RTT。下面是其中部分技巧：

• 使用構建在移動應用中的靜態內容緩存；
• 讓應用同源服務器保持隨時可用的連接；
• 在世界各地部署新的源服務器；
• 在源服務器中使用具備內容緩存、內容轉發和負載均衡特性的NGINX反向代理。

Ilya Grigorik的博文“借助預連接減少往返”是一篇相當不錯的文章。雖然本指南主要討論瀏覽器和Web應用，但同樣的概念可以供移動應用開發人員使用。

此外，從1.9.5版本開始，NGINX提供了HTTP/2支持。這是避免連接建立時間的最好方式，因為HTTP/2在單個隧道中執行所有請求。（額外的好處：不需要修改HTTP/1.1應用程序的語義。）當然，為了充分利用HTTP/2，你必須放棄使用“域名碎片（domain sharding）”，這是一種繞過瀏覽器最大端點連接上限的傳統技巧。

請求處理時間（RPT）

對于簡單應用而言，服務器端處理可能很快，但請求需要數百毫秒甚至更長時間才能返回也很常見。取決于請求性質的不同，這可能大相徑庭。

腳本和數據庫查詢優化是容易處理的問題，但應用程序設計優化可能會讓你更上一層樓。技巧是尋找方法將阻塞等待變成并行工作。

最后，單臺應用程序服務器不足以支撐繁忙的應用。隨著請求開始排隊等待，處理延遲成為衡量響應時間的一個主要部分。這就是為什么在應用程序前面部署一個反向代理會徹底改變游戲規則。它會解鎖“超能力”，如負載均衡、內容緩沖、內容轉發和“微緩存（micro-caching）”。

總之，如果你能夠找到方法解放應用服務器，那么你的時間就花的非常值。讓服務器專注于業務邏輯和動態內容生成——就是這樣。

響應傳送時間（RDT）

我將響應傳送時間大概定義為應用服務器生成響應以及傳送給用戶（或者CDN邊緣節點）所耗費的時間。

根據我們設定的目標和我們正在構建的應用的類型，我們可以用不同的方式優化RDT。例如，一個文件共享應用可能會將下載周轉時間作為關鍵指標。另一方面，一個實時視頻流應用可能會測量向用戶傳送視頻的前10秒所耗費的時間，以便媒體播放器開始播放。

為了改善這些指標，我們應該考慮：1）響應正文的處置和大小；2）響應正文的編碼和緩存；3）服務多個用戶的吞吐效率和規模效應。

來源：InfoQ