Web 應用效能提升 10 倍的 10 個建議

提升 Web 應用的效能變得越來越重要。線上經濟活動的份額持續增長，當前發達世界中 5 % 的經濟發生在網際網路上（檢視下面資源的統計資訊）。 我們現在所處的時代要求一直線上和互聯互通，這意味著使用者對效能有更高的期望。如果網站響應不及時，或者應用有明顯的延遲，使用者很快就會跑到競爭者那邊去。

例如，Amazon 十年前做的一項研究表明，網頁載入時間減少 100 毫秒，收入就會增加  1%。最近另一項研究凸顯了一個事實，就是有一半以上的受調查網站經營者說他們會因為應用的效能不好，而損失收入或客戶。

一個網站需要多快？網頁載入時間每增加 1 秒鐘，就會有 4 % 的使用者選擇離開。頂尖的電子商務網站把第一次互動時間控制在 1-3 秒內，這樣帶來了很高的轉換率。很明顯 Web 應用效能的風險很高而且還在持續增長。

提升效能說起來容易，實現起來卻很難。為了幫助大家，這篇文章提出了十個建議，可以讓網站的效能提升 10 倍。本篇作為系列文章的第一篇，詳細描述瞭如何藉助一些驗證過的優化技術和一點來自 NGINX 的幫助，就能提升應用的效能。該系列還概述了在安全性方面可能獲得的改善。

建議一、利用反向代理伺服器加速和保護應用

如果 Web 應用執行在一臺獨立的電腦上，效能問題的解決方案是顯而易見的：換一臺更快的電腦，裡面加上更多的處理器、記憶體、快速磁碟陣列等等。然後在這臺新電腦上執行 WordPress 服務、Node.js 應用、Java 應用等等，會比以前快很多。（如果應用需要訪問伺服器，方案還是很簡單：換兩臺更快的電腦，用更快速的連線把它們連線起來。）

但電腦速度可能不是問題所在。通常 Web 應用執行緩慢，是由於電腦一直在不同的任務間切換：同成千上萬的客戶互動、訪問磁碟上的檔案、執行應用程式碼和其它的任務。應用伺服器可能會因為下面這些問題而崩潰 —— 記憶體耗盡、把很多的資料從記憶體交換到磁碟上、以及很多請求都在等待一個類似磁碟 I/O 的單個任務。

你應該採用一種完全不同的方式，而不是升級硬體：增加一個反向代理伺服器來分擔這些任務。這臺反向代理伺服器設定在執行應用的電腦之前，用來處理網路流量。只有這臺反向代理伺服器直接連到網路上，它和應用伺服器通過一個快速的內部網路進行通訊。

利用這臺反向代理伺服器，應用伺服器就不用等著和 Web 應用的使用者進行互動，它可以專注在建立網頁，並通過反向代理伺服器把它們傳送到網路上。因為應用伺服器不必再等待客戶的響應，所以能以最優的速度執行。

增加一臺反向代理伺服器也增加了 Web 伺服器的彈性。如果一臺伺服器過載了，很容易增加另一臺同型別的伺服器。如果一臺伺服器當機，也很容易把它換掉。

因為反向代理伺服器帶來的靈活性，它也成為了很多其它效能提升方法的先決條件，比如：

• 負載均衡（檢視 建議二）—— 反向代理伺服器上執行一個負載均衡器，把流量平均分配給一堆應用伺服器。由於負載均衡器的引入，在增加應用伺服器時可以完全不用修改應用程式。
• 快取靜態檔案（檢視 建議三）—— 直接請求的檔案，比如圖片或者程式碼檔案，可以存在反向代理伺服器上，並直接傳送給客戶端，這樣可以更快地提供服務，分擔了應用伺服器的負載，可以讓應用執行得更快。
• 保護網站 —— 反向代理伺服器可以設定較高的安全級別，通過監控進快速識別和響應攻擊，這樣就可以把應用伺服器保護起來。

NGINX 軟體是專門設計用做反向代理伺服器的，具有上述這些附加功能。NGINX 利用事件驅動處理的方法，比其它傳統的伺服器更加高效。NGINX Plus 增加了更多反向代理的高階功能和支援，包含應用程式健康檢查、特定請求路由和高階快取等

建議二、增加一個負載均衡器

增加一個負載均衡器是一個相對簡單的改動，而且會大幅度地改善網站的效能和安全性。你可以利用負載均衡器把業務分配給一些伺服器，而不是建造一臺更大更強的 Web 核心伺服器。就算應用程式編寫得很爛或者擴充套件性很差，負載均衡器都能提升使用者體驗而不需要任何其它的改動。

負載均衡器首先是一個反向代理伺服器（檢視建議一）—— 它接收網路流量，並把請求轉交給另一個伺服器。一個竅門就是讓負載均衡器支援兩臺以上的應用伺服器，利用一個選擇演算法在伺服器間分配請求。最簡單的方法就是輪詢，每個新請求傳送給列表中的下一臺伺服器。其它方法包括把請求傳送給活動連線數量最少的伺服器。NGINX Plus 可以在同一臺伺服器上維持一個給定的使用者會話，這個功能被稱為會話永續性。

負載均衡器可以極大地改善效能，因為它們避免讓一臺伺服器過載，而其它伺服器卻處於空閒的狀態。它們也很容易擴充套件 Web 伺服器的能力，增加相對便宜的伺服器並確保它們物盡其用。

負載均衡可以運用在很多協議上，包含HTTP、HTTPS、SPDY、HTTP/2、WebSocket、FastCGI、SCGI、uwsgi、memcache，還有一些應用程式，包含基於 TCP 的應用和 L4 協議。分析 Web 應用使用了什麼技術和效能落後在什麼地方。

同一臺伺服器或者用於負載均衡的伺服器，還能處理其他任務，包含 SSL 終端、支援客戶端使用的 HTTP/1/x 和 HTTP/2、以及快取靜態檔案。

NGINX 通常被用於負載均衡：想了解更多，請參考這些資料，一篇介紹性的文章、一篇關於配置的文章、一本電子書和相關的網路課程和相關文件。我們的商業版本（NGINX Plus），支援更多負載均衡的特殊功能，比如基於伺服器響應時間的路由規劃，和基於微軟 NTLM 協議的負載均衡。（譯者注：NTLM 是NT LAN Manager的縮寫，NTLM 是 Windows NT 早期版本的標準安全協議。）

建議三、快取靜態和動態內容

快取通過更快地向客戶端提供內容來改善 Web 應用的效能。快取包含一些策略：對內容預處理以便更快地釋出、在更快的裝置上儲存內容、在更靠近客戶端的地方儲存內容，或者上述方法的組合。

有兩種不同型別的快取需要考慮：

• 靜態內容的快取。不經常變化的檔案，比如影像檔案（JPEG，PNG）和程式碼檔案（CSS，JavaScript），可以存在一個邊緣伺服器上，以便在記憶體或磁碟上進行快速檢索。
• 動態內容的快取。很多 Web 應用為每個頁面請求生成新的 HTML。通過簡單地將已經生成 HTML的副本儲存一小段時間，就可以大幅度減少需要生成頁面的總數，釋出這些已經生成的 HTML 副本已經足夠滿足需求了。

比如一個網頁每秒有十次訪問，把它快取 1 秒鐘，這個網頁 90% 的請求都可以用快取滿足。如果你單獨快取靜態內容，甚至最新生成的網頁也會大量包含這些快取的內容。

Web 應用生成快取內容主要有三種技術：

• 讓內容更靠近使用者。內容副本靠近使用者，可以減少傳輸時間。
• 把內容存在更快的電腦上。內容可以儲存在更快的電腦上以便加快檢索。
• 把內容移出過載的電腦。有時候電腦執行一個特定任務比基準效能要慢，這是因為它同時還在忙其他任務。把快取設定在另一臺電腦上，都能提升有快取資源和沒有快取資源的效能，因為這臺主機不再過載了。

設定 Web 應用的快取從 Web 應用伺服器開始，是從內到外來實現的。首先，快取動態內容，減輕了應用伺服器的負擔。接下來，快取靜態內容（包括原本是動態內容的臨時副本），進一步分擔應用伺服器的負擔。然後把快取從應用伺服器移到更快的、距離使用者更近的電腦上，這樣卸下了應用伺服器的負擔，減少了檢索和傳輸的時間。

提高快取可以大大加快應用程式。大多數網頁中，一半以上的內容都是靜態資料（比如大的影像檔案）。在沒有快取的情況下，檢索和傳輸資料可能要花費好幾秒鐘，但如果資料快取在本地，只需要幾分之一秒就可以。

舉一個例子說明實際上如何使用快取，NGINX 和 NGINX Plus 用兩條指令來建立快取：proxy_cache_path 和 proxy_cache。你指定了快取的位置和大小、檔案儲存在快取的最長時間和其它引數。使用的第三條指令（也相當常用），proxy_cache_use_stale，甚至可以在伺服器忙碌或掛掉而不能提供最新內容的情況下，由快取直接提供過期的內容，給客戶端提供一些東西總比什麼都沒有強。從使用者的角度來看，這會大大改善網站和應用的正常執行時間。

NGINX Plus 有一些高階的快取功能，包括支援快取清除，和將快取狀態視覺化並顯示在 dashboard 上，用於監控實時活動。

關於 NGINX 快取的更多資訊，可以參考相關文件和 《NGINX Plus 管理指南》的「NGINX 內容快取」章節。

注意：快取跨越了組織間的界限，讓從事應用開發的人、進行資本投資決策的人和維護網站的人都參與其中。成熟的快取策略就像這裡提到的，很好得體現了DevOps 方式的價值，也就是應用程式設計師、架構師和運維人員等各方力量都團結起來，努力達成對網站的功能、響應時間、安全性和業務結果（比如完成的交易量或銷售額）的要求。

（譯者注：DevOps 不僅僅是一種軟體的部署方法。 它通過一種全新的方式，來思考如何讓軟體的作者（開發部門）和運營者（運營部門）進行合作與協同。）

建議四、壓縮資料

壓縮是一個有巨大潛能的效能加速器。已經有很多精心設計和高效的壓縮標準，有針對影像的（JPEG 和 PNG）、視訊的（MPEG-4）、音樂的（MP3）等等。這些標準都可以大幅減少檔案的大小。

文字資料 —— 包含 HTML（包含了純文字和 HTML 標籤）、CSS 和類似 JavaScript 的程式碼，這些資料通常不經過壓縮就進行傳輸了。壓縮這些資料會大大改善對 Web 應用效能的體驗，特別是那些連線緩慢或受限的移動客戶端。

這是因為使用者在和網頁互動時，文字資料通常已經足夠了，而多媒體資料就需要更多的支援。智慧內容壓縮可以減少 HTML、Javascript、CSS 和其它文字內容對頻寬的要求，通常是 30% 或者更多，從而減少載入時間。

如果使用 SSL，壓縮可以減少 SSL 加密的資料量，從而減少一些 CPU 時間。（譯者注：SSL，Security Socket Layer，加密套接字層，一種加密的通訊協議，用在客戶端與伺服器之間。參考建議五。）

壓縮文字資料的方法有所不同。比如，本文的 HTTP/2 章節提到的一種新穎的文字壓縮方案，專門用來壓縮頭部資料。另一個例子是可以在 NGINX 中開啟 GZIP。對文字資料進行預先壓縮後，可以通過 gzip_static 指令直接提供 .gz 的壓縮檔案（給客戶端）。

建議五、優化 SSL/TLS

加密套接字層（SSL）協議及其後繼者 —— 傳輸層安全（TLS）協議，被越來越多得的網站所採用。SSL/TLS 加密了伺服器傳送給使用者的資料，提升了網站的安全性。影響這一趨勢的部分原因是，Google 現在提升了啟用 HTTPS 網站的搜尋排名。

儘管 SSL/TLS 越來越普遍，它們卻是影響許多網站效能的癥結所在。SSL/TLS 降低網站效能有兩個原因：

1. 每當開啟一個新的連線，最初的握手都需要建立加密金鑰。瀏覽器使用 HTTP/1.x 和伺服器建立多條連線，隨著伺服器的增多，連線會成倍增加。
2. 伺服器上加密資料，客戶端解密資料，這些都是持續的開銷。

為了鼓勵使用 SSL/TLS，HTTP/2 和 SPDY （在下一章節詳細介紹）的作者在設計協議時，讓每個瀏覽器會話只使用一個連線。這樣大大減少了 SSL 開銷的一個重要來源。但是，在提升基於 SSL/TLS 的應用效能方面，還是有很多可以做的事情。

優化 SSL/TLS 的機制因 Web 伺服器而有所差別。比如，NGINX 使用 OpenSSL，執行在標準硬體上，提供類似專用硬體解決方案的效能。NGINX SSL 效能解決方案有詳細的文件、減少了 SSL/TLS 加解密對 CPU 和 時間的消耗。

此外，這篇文章中還詳細介紹了提升 SSL/TLS 效能的各種方式。簡單總結一下，這些技術包括：

• 會話快取。使用 ssl_session_cache 指令，快取 SSL/TLS 加密每個新連線所使用的引數。
• 會話標籤或 ID。這些特定 SSL/TLS 會話資訊都存在一個標籤或 ID 中，所以可以順暢地重用一個連線，而不需要再次握手。
• OCSP 封裝。快取 SSL/TLS 證照資訊，來縮短握手時間。（譯者注：OCSP，Online Certificate Status Protocol，線上證照狀態檢查協議（RFC6960），用來向 CA 站點查詢證照狀態，比如是否撤銷。通常情況下，瀏覽器使用 OCSP 協議發起查詢請求，CA 返回證照狀態內容，然後瀏覽器接受證照是否可信的狀態。這個過程非常消耗時間，因為 CA 站點有可能在國外，網路不穩定，RTT 也比較大。那有沒有辦法不直接向 CA 站點請求 OCSP 內容呢？OCSP 封裝（stapling） 就能實現這個功能。簡單原理就是瀏覽器發起 client hello 時會攜帶一個 certificate status request 的擴充套件，伺服器看到這個擴充套件後將 OCSP 內容直接返回給瀏覽器，完成證照狀態檢查。由於瀏覽器不需要直接向 CA 站點查詢證照狀態，這個功能對訪問速度的提升非常明顯。 ）

NGINX 和 NGINX Plus 可以用在 SSL 或 TLS 終端上 —— 當和其它伺服器進行明文通訊時，對客戶端流量進行加解密。按照這些步驟設定 NGINX 或 NGINX Plus，就能用在 SSL 或 TLS 終端上。當用在接受 TCP 連線的伺服器上，NGINX Plus 還有特別的設定步驟。

建議六、實現 HTTP/2 或 SPDY

對於已經使用 SSL/ TLS 的網站而言，因為 HTTP/2 和 SPDY 中的一個連線只需要一次握手，所以它們很有可能提升效能。對於沒有使用 SSL/TLS 的網站，改到 SSL/TLS 會讓效能變慢， 而 HTTP/2 和 SPDY 對 SSL/TLS 的效能改進，就和效能下降的效果抵消了。

（譯者注：SPDY，一種開放的網路傳輸協定，由Google開發，用來傳送網頁內容。基於傳輸控制協議（TCP）的應用層協議 。Google最早是在Chromium中提出該協議。目前已經被用於Google Chrome瀏覽器中來訪問Google的SSL加密服務。SPDY並不是首字母縮略字，而僅僅是”speedy”的縮寫。）

Google 在 2012年 引入 SPDY ，以實現比 HTTP/1. x 更快的效能。HTTP/2 基於 SPDY，最近剛被採納為 IETF 標準。SPDY 已被廣泛支援，不過很快就要被HTTP/2 所取代。

SPDY 和 HTTP/2 的關鍵特性是僅用一條單一連線而不是多條連線。這條連線是被複用的，同時可以有多個請求和應答在上面傳輸。

這些協議充分發揮了單條連線的最大功效，避免了 HTTP/1.x 需要建立和管理多條連線的開銷。使用單條連線對於 SSL 特別有幫助，因為這樣最大程度地減少了 SSL/TLS 建立一個安全連線所需的握手次數，因為握手通常是比較耗時的。

SPDY 協議需要使用到 SSL/TLS，HTTP/2 的官方說法是不需要用到它們，但是目前支援 HTTP/2 的瀏覽器只有在 SSL/TLS 被開啟的情況下，才會用到 SSL/TLS。也就是說，只有當一個網站使用 SSL 並且它的伺服器接受 HTTP/2 流量時，一個支援 HTTP/2 的瀏覽器才可以使用 SSL/TLS。否則，這個瀏覽器還是基於 HTTP/1.x 進行通訊。

一旦實現了 SPDY 或者 HTTP/2，你就不再需要傳統的 HTTP 效能優化方法，比如區域切分、資源整合和雪碧圖。（譯者注：image spriting，工作原理是一堆的影像（稱為“sprites”,精靈）合併成一張大的影像（國內稱為雪碧圖），以達到減少 HTTP 的請求數量）這些改動讓程式碼和部署變得更加簡單，也更容易管理。要了解 HTTP/2 上相關改動的更多資訊，可以參考這篇白皮書。

NGINX 作為支援這些協議的一個例子，從一開始就支援 SPDY，目前很多使用 SPDY 的網站都在執行 NGINX。 NGINX 很早就支援 HTTP/2 了，2015 年 9 月 NGINX 的開源版本 和 NGINX Plus 就已經支援了。

我們 NGINX 希望有朝一日大部分網站都可以使用 SSL，並遷移到 HTTP/2。這會提升安全性，同時由於找到和實現了新的優化方法，程式碼會更加簡潔而且效能更好。

建議七、更新軟體版本

一個提升應用效能的簡單方法，就是為軟體技術棧選擇穩定的、效能好的元件。此外，高質量元件的程式設計師願意加班追求效能的提升和儘快修正 bug，所以最好使用軟體最新的穩定版本。新的釋出會得到程式設計師和使用者社群的更多關注。新版本還會利用最新的編譯器優化技術，包含對新硬體的優化。

穩定的新版本通常都相容老版本，而且有更好的效能。如果你持續更新軟體，很容易享受到效能優化、bug 修正和安全報警等諸多好處。

一直使用軟體的老版本，還會讓你不能使用到新功能。比如，上面提到的 HTTP/2 現在需要使用 OpenSSL 1.0.1。從 2016 年中開始，HTTP/2 就需要使用 OpenSSL 1.0.2，OpenSSL的這個版本是在 2015 年 1 月釋出的。

NGINX 使用者可以使用最新版本的 NGINX  開源軟體或者 NGINX Plus，新功能都包含其中，比如套接字切分和執行緒池（檢視下面），而且效能還在持續優化中。接下來仔細檢視技術棧的軟體，並儘可能快地使用最新的版本。

建議八、優化 Linux 效能

現在大多數 Web 伺服器的底層作業系統都是基於 Linux 的，所以 Linux 作為基礎設施的基礎，在效能提升方面有很大的空間。預設情況下，很多 Linux 系統被優化成儘可能少地佔用資源，以便適應通常的桌面工作。這意味著 Web 應用程式用例至少需要進行最大效能的優化。

Linux 針對 Web 伺服器所做的優化。以 NGINX 為例，在加速 Linux 時，需要考慮這些重要的改動：

• 緩衝佇列。如果有的連線看上去沒有響應了，試著增大 net.core.somaxconn 看看，這個引數代表可以排隊等待的最大連線數。如果已存在的連線限制太小，你會看到錯誤訊息，可以逐漸增大引數直至錯誤訊息消失。
• 檔案描述符。NGINX 在每個連線上使用兩個檔案描述符。如果系統要服務很多連線，需要增大 sys.fs.file_max 和 nofile 這兩個引數以應對增加的負載，前者是系統範圍內檔案描述符的限制，後者是使用者檔案描述符的限制。
• 臨時埠。當作為代理時，NGINX 為每個上行伺服器建立了臨時埠。你可以通過設定 net.ipv4.ip_local_port_range，來增加埠值的可用範圍。你還可以設定 net.ipv4.tcp_fin_timeout，減少超時來重新使用一個不活躍的埠，以便更快地週轉。

你可以檢視《NGINX 效能優化指南》（伯樂線上正在翻譯中），瞭解如何優化 Linux 系統，以便能毫不費力地處理大量的網路流量。

建議九、優化 Web 伺服器的效能

無論你使用哪一種 Web 伺服器，都需要為 Web 應用效能對它進行優化。下面的建議普遍適用於任何一個 Web 伺服器，但有一些是針對 NGINX 的特別設定。這些優化的關鍵點包括：

• 訪問日誌。可以把請求記錄先快取在記憶體中，然後一起寫入磁碟，而不是把每筆請求立刻寫到磁碟上。NGINX 使用 access_log 指令和 buffer=size 引數，在記憶體緩衝填滿時，把日誌記錄寫入磁碟。可以使用 flush=time 引數，在特定時間後將緩衝內容寫入磁碟。
• 緩衝區。緩衝區可以將一部分應答儲存在記憶體中，直至緩衝被填滿了，這樣會讓與客戶端之前的通訊更加高效。不能存入記憶體中的應答被寫入磁碟，這樣會導致效能的下降。當 NGINX 緩衝開啟的時候，你可以通過 proxy_buffer_size 和 proxy_buffer 這兩個指令來進行管理。
• 客戶端保活時間。保持連線可以減少開銷，特別是使用 SSL/TLS 的時候。在 NGINX 上，你可以通過增加 keepalive_request 的最大數量，來設定客戶端在指定連線上的請求數量，這個引數的預設值是 100 ，你還可以增加 keepalive_timeout 讓連線在開啟狀態上持續得更久一些，從而更快地響應後續的請求。
• 上行保活時間。上行連線也就是指連到應用伺服器、資料庫伺服器等這些連線，它們也可以從保持連線中受益。對於上行連線，你可以增大 keepalive，這個參數列示每個工作程式中有多少空閒的保活連線是處於開啟狀態的。這樣會增加重用連線的數量，減少開啟全新連線的需求。保活的更多資訊，參考這篇文章。
• 限制。限制客戶端所使用的資源也能提升效能和安全性。NGINX 可以通過 limit_conn 和 limit_conn_zone 指令限制一個給定源的連線數量，limit_rate 指令則用來限定頻寬。這些設定可以阻止一個合法使用者“佔用”資源，也可以防止攻擊。limit_req 和 limit_req_zone 指令限制客戶端的請求。對於上行伺服器的連線而言，可以在上行配置段中，使用 server 指令和 max_conns 引數。這樣限制了連線到上行伺服器的數量，可以防止過載。相關的 queue 指令建立了一個佇列，當 max_conns 限制超過時，可以在一定時間內儲存一定數量的請求。
• 工作程式。工作程式負責處理請求。NGINX 採用了基於事件的模型，以及和作業系統相關的機制，高效地把請求分配給工作程式。work_processes 的推薦值是在每個 CPU 上設定為 1。絕大多數系統出於需要，會在保證安全的前提下提高 work_connections （預設值 512）的最大值，你可以通過實驗來找到適合系統的值。
• 套接字切分。通常用一個單獨的監聽套接字將新連線分配給各個工作程式。套接字切分會為每個工作程式建立一個監聽套接字，當監聽套接字可用時，核心會把連線分配給它們。這樣在多核系統中可以減少對鎖的競爭和提升效能。執行 listen 指令時配合 reuseport 引數，就可以開啟套接字切分的功能。
• 執行緒池。任何一個計算機程式都可能被一個慢速操作所拖累。對 Web 伺服器軟體來說，訪問磁碟會拖累很多快速的操作，比如在記憶體上進行計算或者複製資訊。當一個執行緒池被引入，可以把這個慢速操作分配給一個獨立的任務，主程式仍然處理快速操作。磁碟操作完成後，結果再返回給主程式。 在 NGINX 中會把 read() 和 sendfile() 這兩個系統呼叫分散到執行緒池上。

小提示：當改動任何系統或服務上的設定時，一次只修改一個設定，然後再測試效能。如果這個改動造成問題，或者沒有讓網站變快，把它改回來就好了。

關於優化 NGINX 的更多資訊，請參考這篇文章。

建議十、監控實時活動來解決問題和瓶頸

開發和釋出高效能應用的關鍵，在於密切和實時地關注應用程式在現實情況下的效能。你必須能夠監控特定裝置的活動和網站的基礎設施。

大多數監控網站的活動都很被動 —— 它只告訴你將會發生什麼，讓你自己去發現問題和解決問題。

監控可以抓到不同型別的問題。它們包含：

1. 伺服器當機。
2. 伺服器不穩定，容易掉線。
3. 伺服器大概率出現緩衝失效。
4. 伺服器傳送的內容不正確。

你可以使用 New Relic 或 Dynatrace 這種全球性的應用效能監控工具，來監控遙遠地方載入頁面的時間，也可以利用 NGINX 監控應用程式的釋出。當你考慮是否需要給基礎設施擴容來維持流量時，應用效能資料可以告訴你這些優化是否真能給使用者帶來很大的改善。

NGINX Plus 增加了檢查應用程式健康的功能 —— 綜合一些定期重複性的操作，以及在問題發生時報警，這樣可以快速地定位和解決問題。NGINX Plus 還有會話耗盡功能 —— 當任務完成後終止新的連線，以及慢啟動的能力 —— 允許負載均衡叢集中的一臺伺服器，從剛修復的狀態慢慢趕上來。如果使用得當，健康檢查可以在發生影響使用者體驗的重大問題前，就定位出問題。會話耗盡和慢啟動，允許更換伺服器，並保證在過程中不會對效能和正常的執行時間造成不好的影響。下圖是一個在 NGINX Plus 中整合了實時活動監控的 dashboard，上面顯示了Web 基礎設施和伺服器、TCP 連線以及快取等相關資訊。

總結：如何看到效能提升 10 倍

能用在每個 Web 應用上的效能提升方法千差萬別，並且最後的效果也取決於預算、付出的時間和已有的實現等等。那麼如何讓你自己的應用達到效能提升 10 倍的目標呢？

雖然你們遇到的情況肯定會不一樣，為了幫助理解每種優化方法的影響，這裡列出一些上面詳細討論的要點：

• 反向代理伺服器和負載均衡。如果沒有做負載均衡，或者負載均衡做得很爛，都會造成效能很差。增加一個反向代理伺服器，比如 NGINX，就可以防止 Web 應用在記憶體和磁碟間往復切換。負載均衡可以將處理從過載的伺服器移到其他可用的伺服器上，並且很容易進行擴充套件。這些改動可以大幅度地提升效能，和現在實現的最差情況相比，很容易實現 10 倍的效能提升，但實質上整體效能的提升可能沒有這麼大。
• 快取動態和靜態內容。如果有一個伺服器已經過載了，它既是 Web 伺服器又是應用伺服器，通過快取動態內容就可以在峰值時刻提升 10 倍的效能。快取靜態檔案也能實現個位數字的效能提升。
• 壓縮資料。利用多媒體檔案的壓縮格式，比如圖片採用 JPEG 格式、影像採用 PNG 格式、電影採用 MPEG-4 格式、音樂採用 MP3 格式，這樣就能在很大程度上提升效能。一旦這些格式都用上，壓縮文字資料（程式碼和 HTML）的頁面載入速度可以提升 2 倍。
• 優化 SSL/TLS。安全握手對效能有很大影響，所以優化它們可以帶來 2 倍的改善，特別是文字很多的網站。在 SSL/TLS 條件下，優化多媒體檔案改善很小。
• 實現 HTTP/2 和 SPDY。當和 SSL/TLS 一起使用時，這些協議會讓整個網站的效能大幅度地提升。
• 優化 Linux 和 Web 伺服器軟體（例如 NGINX）。優化緩衝區、保持連線、將耗時的任務分散到一個獨立的執行緒池上都能大幅提升效能。比如執行緒池運用在對磁碟操作頻繁的任務上會帶來指數級的提速。

我們希望你自己嘗試下這些技術。我們希望聽到你在某個應用程式上提升了效能。你可以在下面的評論中分享你的結果，或者把你的故事用 #NGINX 和  #webperf 標籤推送到 twitter 上！

網際網路上的統計資源

• Statista.com – Share of the internet economy in the gross domestic product in G-20 countries in 2016
• Load Impact – How Bad Performance Impacts Ecommerce Sales
• Kissmetrics – How Loading Time Affects Your Bottom Line (infographic)
• Econsultancy – Site speed: case studies, tips and tools for improving your conversion rate

打賞支援我翻譯更多好文章，謝謝！

打賞譯者