實現 10 倍應用效能提升的 10 個技巧

語言: CN / TW / HK

時間 2023-01-11 12:02:12 NGINX開源社群

主題:

原文作者：Floyd Smith of F5

原文連結：實現 10 倍應用效能提升的 10 個技巧

轉載來源：NGINX 官方網站

Web 應用效能優化迫在眉睫。線上經濟活動份額不斷增長，發達世界的網際網路經濟已佔經濟總量的 5% 以上（請參見下文的網際網路統計資料來源）。在這個始終線上、超級互聯的現代世界，使用者的期望已經今非昔比。如果您的網站沒有立即做出響應，或者如果您的應用無法毫不延遲地執行，使用者轉身就會投向您的競爭對手。

例如，Amazon 近 10 年前的一項研究證明，頁面載入時間每減少 100 毫秒，收入就會增加 1% —— 10 年前就已如此，更何況是現在。最近的另一項研究也強調指出，超過一半的受訪網站所有者表示他們由於應用效能不佳失去了收入或客戶。

一個網站到底多快才行？頁面載入每延長 1 秒鐘，就有大約 4% 的使用者走掉。主要電商網站的首次互動時間從 1 秒到 3 秒不等，這個區間的轉化率最高。Web 應用效能的重要性由此可見，並且可能還會與日俱增。

想要提高效能很容易，難的是怎麼看到結果。為此，本文提出了幫您實現 10 倍網站效能提升的 10 個技巧。本文是一系列博文的開帖之作，詳細介紹瞭如何藉助一些久經考驗的優化技術以及 NGINX 的一些支援提高應用效能。該系列還概括介紹了您可能因此而獲得的安全性方面的改進。

技巧 1 —— 使用反向代理伺服器加速並保護應用

如果您的 Web 應用在一臺機器上執行，那要提升其效能非常簡單：換一臺更快的機器、多加幾顆處理器、增加 RAM、換成高速磁碟陣列即可，這樣新機器就可以更快地執行 WordPress 伺服器、Node.js 應用和 Java 應用了。（如果您的應用需要訪問資料庫伺服器，解決辦法仍然很簡單：找兩臺更快的機器，用更快的網路連起來就行了。）

問題是，機器的速度可能並不是問題所在。Web 應用通常執行很慢，因為計算機要在不同型別的任務之間切換：通過數千個連線與使用者互動、訪問磁碟檔案、執行應用程式碼等等。應用伺服器可能會因此而崩潰 —— 記憶體耗盡、將記憶體塊交換到磁碟、讓許多請求等待一個任務（比如磁碟 I/O）等。

除了升級硬體之外，您還可以採用一種完全不同的方法：新增反向代理伺服器來解除安裝一些任務。反向代理伺服器位於執行應用的機器的前面，負責處理網際網路流量。只有反向代理伺服器直接連線到網際網路，與應用伺服器的通訊是通過一個高速內網進行的。

反向代理伺服器可以讓應用伺服器不必再等待使用者與 Web 應用的互動，而是專注於構建頁面，剩下的傳送任務則交由反向代理來執行。由於無需等待客戶端響應，應用伺服器可以以接近優化基準測試所達到的速度執行。

新增反向代理伺服器還可以增加 Web 伺服器設定的靈活性。例如，如果執行既定任務的伺服器過載了，您可以輕鬆新增一臺同類型的伺服器；如果一臺伺服器宕機，那麼替換它也不難。

鑑於這種靈活性，反向代理伺服器往往也是許多其他效能優化手段的先決條件，例如：

負載均衡（見技巧 2） —— 在反向代理伺服器上執行負載均衡器，以便在多個應用伺服器之間均勻地共享流量。藉助負載均衡器，您無需更改應用即可新增應用伺服器。
快取靜態檔案（見技巧 3） —— 直接請求的檔案（如影象檔案或程式碼檔案）可以儲存在反向代理伺服器上，並直接傳送到客戶端，這樣不僅可以更快地提供資產，還能減輕應用伺服器的負擔，進而加快應用執行速度。
保護站點安全—— 反向代理伺服器可以配置為高安全性並進行監控，以便快速識別和響應攻擊，保護應用伺服器的安全。

NGINX 軟體一開始的設計定位就是具有上述附加功能的反向代理伺服器。NGINX 採用了事件驅動型處理方法，因此比傳統伺服器效率更高。NGINX Plus 增添了更多高階反向代理功能，比如應用健康檢查、特定請求的路由、高階快取，並提供技術支援。

技巧 2 —— 新增負載均衡器

新增負載均衡器相對簡單，但卻能顯著提升站點效能和安全性。您不需要升級核心 Web 伺服器的硬體效能或規模，而是直接使用負載均衡器將流量分發到多臺伺服器。即使應用寫得不好或者難以擴充套件，負載均衡器也可以在應用不做出任何更改的情況下改善使用者體驗。

負載均衡器首先是一個反向代理伺服器（見技巧 1），負責接收網際網路流量並將請求轉發給其他伺服器。這裡的關鍵在於負載均衡伺服器可以支援兩臺或更多應用伺服器，使用您選擇的演算法在不同的伺服器間分配請求。最簡單的負載均衡方法是輪詢，其中每個新請求都會被髮送到列表中的下一臺伺服器。將請求傳送到活動連線數最少的伺服器也是常用的方法之一。NGINX Plus 還具有會話保持功能，即將當前使用者的多個會話保持在同一臺伺服器上。

負載均衡器可以避免出現一臺伺服器過載而其他伺服器過閒的情況，從而顯著提效能。此外，Web 伺服器擴容也會變得簡單，您可以新增相對便宜的伺服器，並確保物盡其用。

可以進行負載均衡的協議包括 HTTP、HTTPS、SPDY、HTTP/2、WebSocket、FastCGI、SCGI、uwsgi、memcached 以及其他應用型別，包括了基於 TCP 的應用和其他四層協議。您應該分析您的 Web 應用，確定它的型別以及效能短板是什麼。

用於負載均衡的一臺或若干臺伺服器還可以同時處理其他任務，例如 SSL 終止、按客戶端來選擇 HTTP/1._x_和 HTTP/2 的使用、靜態檔案快取等。

負載均衡是 NGINX 常用的功能之一。有關更多資訊，請下載我們的電子書：《選擇軟體負載均衡器的五個理由》；有關基本配置說明，請參見《NGINX 和 NGINX Plus 負載均衡：第一部分》；有關完整文件，請參見《NGINX Plus 管理員指南》。NGINX Plus是我們的商業產品，支援更多專業化的負載均衡功能，例如基於伺服器響應時間的負載路由以及 Microsoft NTLM 協議負載均衡。

技巧 3 —— 快取靜態和動態內容

快取可以通過更快地向客戶端交付內容來改善 Web 應用的效能。快取可以運用多種策略：預處理內容以便在需要時快速交付內容、將內容儲存在更快的裝置上、將內容儲存在靠近客戶端的地方等等，這些策略也可以組合運用。

快取有兩種型別：

靜態內容快取—— 影象檔案 (JPEG、PNG) 和程式碼檔案 (CSS、JavaScript) 等不常更改的檔案可以儲存在邊緣伺服器上，以便快速從記憶體或磁碟中檢索。
動態內容快取—— 許多 Web 應用都會為每個頁面請求生成新的 HTML。通過短暫快取一份生成的 HTML 副本，您可以大大減少必須要生成的頁面總數，同時仍然提供足夠滿足需求的新鮮內容。

例如，假設一個頁面每秒被檢視 10 次，那麼快取 1 秒就代表這個頁面有 90% 的請求來自快取。如果您單獨快取各個靜態內容，那麼即使是全新生成的頁面，也可能大部分來自快取的內容。

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

將內容放到更靠近使用者的地方—— 離使用者越近，傳輸時間越少。
將內容放到更快的機器上—— 機器越快，檢索越快。
將內容從過度使用的機器上移除—— 在執行某個特定任務時，機器的執行速度有時會比基準效能慢得多，因為它們忙於其他任務。在不同的機器上快取可以提高快取資源和非快取資源的效能，因為主機過載較少。

Web 應用快取可以由內（Web 應用伺服器）而外的實施。首先，快取動態內容，以減少應用伺服器的負載。其次，快取靜態內容（包括動態內容的臨時副本），以進一步減少應用伺服器的負載。然後，將快取從應用伺服器轉移到更快和/或更靠近使用者的機器上，從而減輕應用伺服器的負擔，縮短檢索和傳輸時間。

優化的快取可以極大地加快應用速度。對於很多網頁來說，靜態資料（例如大影象檔案）往往佔據一半以上的內容。如果不快取，檢索和傳輸此類資料可能會花好幾秒鐘，但是如果將資料快取在本地，可能只花幾分之一秒。

對於快取的實踐應用，我們可以看這樣一個例子：NGINX 和 NGINX Plus 使用兩個指令來設定快取：proxy_cache_path和proxy_cache。您可以指定快取的位置和大小、檔案的最長快取時間以及其他引數。您甚至還可以使用指令proxy_cache_use_stale（相當受歡迎），指示快取在本應提供新鮮內容的伺服器太忙或停機時提供舊檔案，畢竟對客戶端來說，有總比沒有強。這可能會極大地改善您的網站或應用的正常執行時間，給使用者樹立一種十分穩定的形象。

NGINX Plus 具有高階快取功能，包括支援快取清除、在儀表盤上以視覺化的形式顯示快取狀態（以監控實時活動）等。

有關 NGINX 快取的更多資訊，請參見參考文件和《NGINX Plus 管理員指南》。

注意：快取跨越了應用開發人員、資本投資決策人員和實時網路運營人員之間的組織界線。複雜的快取策略（比如本文提到的這些）很好地體現了DevOps的價值，其中應用開發人員、架構師和運營人員攜手合作，朝著保障網站功能、響應時間、安全和業務成效（比如完成的交易或銷售）的目標共同發力。

技巧 4 —— 壓縮資料

壓縮是一個重要的、潛在的效能加速器。圖片（JPEG 和 PNG）、影片 (MPEG-4）和音樂 (MP3) 等檔案都有著精心打造和非常高效的壓縮標準，其中任何一個標準都可以將檔案縮小一個數量級甚至更多。

HTML（包括純文字和 HTML 標籤）、CSS 和程式碼(如 JavaScript）等文字資料經常在不壓縮的情況下進行傳輸。壓縮這些資料可能會對感知到的 Web 應用效能產生特別明顯的影響，尤其是對速度緩慢或移動連線受限的客戶端來說。

這是因為文字資料通常足以讓使用者與頁面進行互動，而多媒體資料可能更多的體現支援性或錦上添花的作用。智慧內容壓縮通常可以將 HTML、Javascript、CSS 和其他文字內容的頻寬需求減少 30% 及以上，並相應地減少載入時間。

如果使用 SSL，壓縮可以減少必須進行 SSL 編碼的資料量，從而抵消壓縮資料所需的一些 CPU 時間。

壓縮文字資料的方法有很多。例如，技巧 6中就提到了一種在 SPDY 和 HTTP/2 中壓縮文字的新穎機制，該機制專門針對請求頭資料進行了調整。還有一個文字壓縮的例子，那就是您可以在 NGINX 中啟用GZIP壓縮功能。在服務中預壓縮文字資料之後，您可以使用gzip_static指令直接提供壓縮的**.gz**檔案。

技巧 5 —— 優化 SSL/TLS

安全套接字層 (SSL) 協議及其升級版傳輸層安全 (TLS) 協議在網站中的應用越來越廣泛。SSL/TLS 通過加密從源伺服器傳輸給使用者的資料來提高站點安全性。Google 現在將 SSL/TLS 的使用作為搜尋引擎排名的加分項，這在某種程度上加速了這一技術的普及。

雖然 SSL/TLS 變得越來越受歡迎，但它們帶來的相關效能問題也困擾著許多網站。SSL/TLS 拖慢網站的原因有兩個：

每當開啟新連線時，建立加密金鑰都需要進行初始握手。瀏覽器使用 HTTP/1._x_時對每臺伺服器建立多個連線的方式加劇了這個問題。
伺服器端加密資料和客戶端解密資料也會帶來持續的開銷。

為了鼓勵人們使用 SSL/TLS，HTTP/2 和 SPDY 協議（見技巧 6）應運而生，這樣瀏覽器只需為每次會話建立一個連線便可，同時也搞定了 SSL 的一大開銷來源。但是，通過 SSL/TLS 交付的應用還有很大的效能提升空間。

SSL/TLS 的優化機制因 Web 伺服器而異。例如，NGINX 使用在標準商用硬體上執行的OpenSSL來提供與專用硬體解決方案相媲美的效能。NGINX 的SSL 效能優化是有據可查的，可以將執行 SSL/TLS 加密和解密的時間及 CPU 消耗降到最低。

此外，本博文還詳細介紹了提升 SSL/TLS 效能的其他方式，簡而言之，這些技術是：

會話快取—— 使用ssl_session_cache指令快取保護每個 SSL/STL 新連線時使用的引數。
Session Ticket 或 ID—— 將特定 SSL/TLS 會話的資訊儲存在 ticket 或 ID 中，這樣無需再次握手即可順利重用連線。
OCSP Stapling—— 通過快取 SSL/TLS 證書資訊縮短握手時間。

NGINX 和 NGINX PLUS 支援 SSL/TLS 終止，即在處理客戶端流量加密和解密的同時，與其他伺服器進行明文通訊。如欲設定 NGINX 或 NGINX Plus 的 SSL/TLS 終止功能，請參見HTTPS 連線和TCP 加密連線的說明。

技巧 6 —— 實施 HTTP/2 或 SPDY

對於已經使用 SSL/TLS 的站點，HTTP/2 和 SPDY 可能會讓效能更上一層樓，因為一個連線僅需要一次握手。對於尚未使用 SSL/TLS 的站點，HTTP/2 和 SPDY 從響應性的角度來看，轉向 SSL/TLS（通常會降低效能）是一種洗禮。

Google 在 2012 年推出了 SPDY，致力於在 HTTP/1._x_之上實現更快的速度。HTTP/2 是 IETF 最近批准的基於 SPDY 的標準。SPDY 得到了廣泛的支援，但很快就會被 HTTP/2 取代。

SPDY 和 HTTP/2 的關鍵功能是使用單個連線而非多個連線。單個連線是多路複用的，因此它可以同時承載多個請求和響應。

通過充分利用一個連線，這些協議避免了設定和管理多個連線（瀏覽器實施 HTTP/1._x_的必要條件）的開銷。使用單個連線對 SSL 尤為有用，因為這可以將 SSL/TLS 建立安全連線所需的握手時間降到最少。

SPDY 協議要求使用 SSL/TLS；HTTP/2 沒有對此作出正式要求，但目前所有支援 HTTP/2 的瀏覽器都只會在啟用 SSL/TLS 的情況下使用它。也就是說，只有當網站使用 SSL 且其伺服器接受 HTTP/2 流量時，支援 HTTP/2 的瀏覽器才能使用 HTTP/2，否則瀏覽器將通過 HTTP/1._x_通訊。

實施 SPDY 或 HTTP/2 後，就用不到域分片 (domain sharding)、資源合併、影象拼合 (image spriting) 等典型的 HTTP 效能優化技術了。這些變動也可以簡化程式碼和部署的管理。如欲詳細瞭解 HTTP/2 帶來的變化，請參閱我們的白皮書：《面向 Web 應用開發人員的 HTTP/2》。

NGINX Supports SPDY and HTTP/2 for increased web application performance

在對這些協議的支援方面，NGINX 從很早就開始支援 SPDY 了，並且現在使用 SPDY 的大多數站點都部署了 NGINX。NGINX 也是率先支援HTTP/2 的開拓者之一，從 2015 年 9 月起，NGINX 開源版和 NGINX Plus 就引入了對 HTTP/2 的支援。

NGINX 希望隨著時間的推移，大多數站點都能完全啟用 SSL 並遷移到 HTTP/2。這不僅有助於提高安全性，而且隨著新型優化技術的發現和實施，效能更高的程式碼也將得到進一步簡化。

技巧 7 —— 更新軟體版本

提高應用效能的一種簡單方法是根據穩定性和效能為您的軟體棧選擇元件。此外，由於高質量元件的開發人員可能會不斷增強效能和修復 bug，使用最新的穩定版軟體是非常划算的。新版本會受到開發人員和使用者社群的更多關注，同時也會利用新的編譯器優化技術，包括對新硬體的調優。

從相容性和效能角度來看，新發布的穩定版本通常也比舊版本更勝一籌。堅持軟體更新還可以讓您在調優、bug 修復和安全警報方面保持優勢。

使用舊版本會妨礙新功能使用。例如，上文提到的 HTTP/2 目前要求使用 OpenSSL 1.0.1.。從 2016 年年中開始，HTTP/2 會要求使用 OpenSSL 1.0.2（於 2015 年 1 月釋出）。

NGINX 使用者可以先從升級到最新版的NGINX或NGINX Plus入手，它們具備套接字分片 (socket sharding) 和執行緒池（見技巧 9）等新功能，並且均會持續進行效能調優。然後再深入檢查一下堆疊中的軟體，儘量遷移到最新版本。

技巧 8 —— 優化 Linux 效能

Linux 是當今大多數 Web 伺服器的底層作業系統。作為基礎架構的基石，Linux 蘊藏著重大的調優潛能。預設情況下，許多 Linux 系統的優化都比較保守，以佔用少量資源、滿足常規桌面工作負載為目標。這意味著在 Web 應用用例中，要想達到最高效能，調優是必不可少的。

Linux 優化因 Web 伺服器而異。以 NGINX 為例，您可以重點考慮從以下幾個方面給 Linux 提速：

積壓佇列 (Backlog Queue)—— 如果有一些連線得不到處理，可以考慮增大net.core.somaxconn的值，即等待 NGINX 處理的最大連線數。如果當前連線限制數太小，就會收到錯誤訊息，您可以逐漸增加此引數，直到錯誤訊息不再出現。
檔案描述符—— NGINX 最多對每個連線使用兩個檔案描述符。如果系統服務於很多連線，則可能需要增大sys.fs.file_max（整個系統範圍內對檔案描述符的限制）以及nofile（使用者檔案描述符限制），以支援增加的負載。
臨時埠—— 當用作代理時，NGINX 會為每個上游伺服器建立臨時埠。您可以使用net.ipv4.ip_local_port_range拉寬埠的值閾，以增加可用埠的數量。您還可以使用net.ipv4.tcp_fin_timeout減少重用非活動埠之前的超時，從而加快週轉。

對於 NGINX，請參見《NGINX 效能調優指南》，瞭解如何優化您的 Linux 系統，使其輕鬆處理大量網路流量！

技巧 9 —— 優化 Web 伺服器的效能

無論您使用哪種 Web 伺服器，都要對其進行調優才能提升 Web 應用的效能。以下建議通常適用於任何 Web 伺服器，其中包含一些針對 NGINX 的特定設定。主要的優化技術有：

訪問日誌—— 不要立即將每個請求的日誌寫到磁碟，可以先將條目放到記憶體緩衝區，然後再批量寫入。對於 NGINX，將buffer=_size_引數新增到access_log指令中，等記憶體緩衝區寫滿後再把日誌寫入磁碟。如果新增flush=_time_引數，緩衝區的內容也會在指定的時間過後寫入磁碟。
緩衝—— 緩衝用於在記憶體中儲存一部分響應，直到緩衝區填滿為止，可以實現與客戶端更高效的通訊。不適合寫入記憶體的響應會被寫入磁碟，導致效能降低。啟用NGINX 緩衝功能後，可以使用proxy_buffer_size和proxy_buffers指令進行管理。
客戶端 keepalive 連線—— Keepalive 連線可以減少開銷，尤其是在使用 SSL/TLS 時。對於 NGINX，您可以增加客戶端通過現有連線發出的keepalive_requests的最大數量（預設值為 100），同時增大keepalive_timeout的值，讓 keepalive 連線保持更長時間的開啟狀態，從而加快後續請求的速度。
Upstream keepalive 連線—— Upstream 連線，即與應用伺服器、資料庫伺服器等伺服器的連線，同樣可以從 keepalive 連線的設定中獲得好處。對於 Upstream 連線，您可以增加keepalive，即為每個 worker 程序保持開啟狀態的空閒 keepalive 連線的數量。這可以增加對連線的重複使用，減少開啟全新連線的需求。有關更多資訊，請參閱我們的博文：《HTTP Keepalive 連線和 Web 效能》。
限流—— 限制客戶端使用的資源可以提升效能和安全性。對於 NGINX，limit_conn和limit_conn_zone指令可以限制來自既定源的連線數，limit_rate則可以限制頻寬。這些設定可以防止合法使用者“侵吞”資源，也可以幫助防止攻擊。limit_req和limit_req_zone指令能夠限制客戶端請求。對於到上游伺服器的連線，您可以在 upstream 配置塊中使用server指令的max_conns引數，以限制到上游伺服器的連線，防止過載。關聯的queue指令會建立一個佇列，在達到max_conns限制後在指定的時間長度內儲存指定數量的請求。
Worker 程序—— Worker 程序負責處理請求。NGINX 採用基於事件的模型和依賴作業系統的機制在 worker 程序之間高效地分發請求。建議將worker_processes的值設定為每個 CPU 一個。如果需要，大多數系統都支援提高worker_connections的最大數值（預設為 512），可以通過試驗找出最適合您的系統的值。
套接字分片 (Socket Sharding)—— 套接字監聽器通常會向所有 worker 程序分發新連線。套接字分片 (Socket Sharding) 為每個 worker 程序建立一個套接字監聽器，由核心在套接字監聽器可用時為其指定連線。這可以減少鎖爭用並提高多核系統的效能。要啟用套接字分片功能，請在listen指令中新增reuseport引數。
執行緒池—— 任何計算機程序都可能會被一個緩慢的操作所拖累。對於 Web 伺服器軟體，磁碟訪問可能阻礙很多較快的操作，例如記憶體中的計算或資訊複製。使用執行緒池時，慢操作會被分配給一組單獨的任務，而主處理迴圈仍然繼續執行較快的操作。磁碟操作完成後，結果會返回到主處理迴圈。NGINX 將read()系統呼叫和sendfile()這兩個操作解除安裝到了執行緒池。

Thread pools help increase application performance by assigning a slow operation to a separate set of tasks

小貼士：如果要更改任何作業系統或支援服務的設定，請一次先更改一項設定，然後測試效能。如果更改引發了問題或者不會加快網站執行速度，那就再改回去。

有關 NGINX Web 伺服器調優的更多資訊，請參見我們的博文：《優化 NGINX 的效能》。

技巧 10 —— 監控實時活動，以解決問題和發現瓶頸

高效的應用開發和交付方法的關鍵在於實時密切監控應用的真實效能。您必須要監控特定裝置和 Web 基礎架構中的活動。

監控站點活動多數時候是被動的 —— 它只告訴您發生了什麼，至於如何發現和解決問題，則是我們自己的事情。

監控可以捕獲以下幾種不同的問題：

伺服器停機。
伺服器執行不穩定，導致連線中斷。
伺服器出現大量快取未命中問題。
伺服器沒有傳送正確的內容。

全域性應用效能監控工具（例如 New Relic 或 Dynatrace）可幫助您遠端監控頁面載入時間，NGINX 則可幫助您監控應用交付這一端。應用效能資料可以顯示，您的優化在什麼情況下對使用者產生了真正的影響，以及什麼情況下要為基礎架構擴容以滿足流量需求。

為了幫助快速發現和解決問題，NGINX Plus 增加了應用感知型健康檢查功能，這類綜合事務（synthetic transaction）會定期重複，在發現問題後向您發出告警。NGINX Plus 還具有會話耗盡功能，能夠在現有任務完成時停止新連線，其慢啟動特性還允許恢復的伺服器在負載均衡組內逐漸升到正常水平。只要使用得當，健康檢查就會幫助您及時發現問題，以免對使用者體驗造成重大影響，會話耗盡和慢啟動則允許您在不降低感知到的效能或正常執行時間的情況下替換伺服器。下圖展示了 NGINX Plus 內建了 Web 基礎架構的實時活動監控儀表盤，涵蓋了伺服器、TCP 連線和快取。

The NGINX Plus dashboard provides detailed statistics for monitoring and managing your infrastructure

結論 —— 實現 10 倍的效能提升

不同的 Web 應用有著不同的效能提升空間，實際的效果取決於您的預算、投入的時間以及當前實施的差距。那麼，如何才能讓您的應用實現 10 倍的效能提升呢？

為了幫助您理解每種優化技術的潛在影響，下面分條列出了文中所述的各項技巧可能帶來的一些改進，希望大家各取所需：

反向代理伺服器及負載均衡—— 沒有負載均衡或者負載均衡不好可能會導致效能極低。新增反向代理伺服器（例如 NGINX）可以防止 Web 應用在記憶體和磁碟之間來回奔波。負載均衡可以將處理任務從過載的伺服器轉移到可用的伺服器，也可以簡化擴充套件。這些改變能夠顯著提升效能，與原有部署方式最差的時候相比，10 倍效能提升是很輕鬆的事，即使不到 10 倍也在總體上有了質的飛躍。
快取動態和靜態內容—— 如果您的 Web 伺服器同時又超負荷地充當應用伺服器，那麼僅快取動態內容就可以在高峰期達到 10 倍的效能提升，快取靜態檔案也可以實現幾倍的效能提升。
壓縮資料—— 使用 JPEG（照片）、PNG（圖形）、MPEG-4（電影）和 MP3（音樂檔案）等媒體檔案壓縮格式可以顯著提升效能。如果這些方式都用上了，那麼壓縮文字資料（程式碼和 HTML）可以將初始頁面載入速度提高兩倍。
優化 SSL/TLS—— 安全握手對效能的影響很大，因此對其進行優化可能會讓初次響應加快兩倍，尤其是對文字內容較多的網站來說。如果是在 SSL/TLS 下優化媒體檔案傳輸，效能優化的效果可能不是很大。
實施 HTTP/2 和 SPDY—— 當與 SSL/TLS 一起使用時，這些協議可能會對網站整體效能帶來增量改進。
Linux 和 Web 伺服器軟體（如 NGINX）調優—— 優化緩衝、使用 keepalive 連線、將耗時的任務解除安裝到獨立的執行緒池等修復措施可以顯著提升效能，例如執行緒池可以將磁碟操作密集型任務的速度提高大約一個數量級。

我們希望大家多多嘗試這些技術，也期待聽到大家在改進應用效能方面的心得。