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 倍的目標呢？

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