提高 web 應用的效能從來沒有比現在更重要過。網路經濟的比重一直在增長；全球經濟超過 5% 的價值是在因特網上產生的（資料參見下面的資料）。這個時刻線上的超連線世界意味著使用者對其的期望值也處於歷史上的最高點。如果你的網站不能及時的響應，或者你的 app 不能無延時的工作，使用者會很快的投奔到你的競爭對手那裡。

舉一個例子，一份亞馬遜十年前做過的研究可以證明，甚至在那個時候，網頁載入時間每減少100毫秒，收入就會增加1%。另一個最近的研究特別強調一個事實，即超過一半的網站擁有者在調查中承認它們會因為應用程式效能的問題流失使用者。

網站到底需要多快呢？對於頁面載入，每增加1秒鐘就有4%的使用者放棄使用。頂級的電子商務站點的頁面在第一次互動時可以做到1秒到3秒載入時間，而這是提供最高舒適度的速度。很明顯這種利害關係對於 web 應用來說很高，而且在不斷的增加。

想要提高效率很簡單，但是看到實際結果很難。為了在你的探索之旅上幫助到你，這篇文章會給你提供10條最高可以提升10倍網站效能的建議。這是一系列介紹提高應用程式效能的第一篇文章，包括充分測試的優化技術和一點 NGINX 的幫助。這個系列也給出了潛在的提高安全性的幫助。

Tip #1: 通過反向代理來提高效能和增加安全性

如果你的 web 應用執行在單個機器上，那麼這個辦法會明顯的提升效能：只需要換一個更快的機器，更好的處理器，更多的記憶體，更快的磁碟陣列，等等。然後新機器就可以更快的執行你的 WordPress 伺服器, Node.js 程式, Java 程式，以及其它程式。（如果你的程式要訪問資料庫伺服器，那麼解決方法依然很簡單：新增兩個更快的機器，以及在兩臺電腦之間使用一個更快的鏈路。）

問題是，機器速度可能並不是問題。web 程式執行慢經常是因為計算機一直在不同的任務之間切換：通過成千上萬的連線和使用者互動，從磁碟訪問檔案，執行程式碼，等等。應用伺服器可能會抖動thrashing-比如說記憶體不足、將記憶體資料交換到磁碟，以及有多個請求要等待某個任務完成，如磁碟I/O。

你可以採取一個完全不同的方案來替代升級硬體：新增一個反向代理伺服器來分擔部分任務。反向代理伺服器 位於執行應用的機器的前端，是用來處理網路流量的。只有反向代理伺服器是直接連線到網際網路的；和應用伺服器的通訊都是通過一個快速的內部網路完成的。

使用反向代理伺服器可以將應用伺服器從等待使用者與 web 程式互動解放出來，這樣應用伺服器就可以專注於為反向代理伺服器構建網頁，讓其能夠傳輸到網際網路上。而應用伺服器就不需要等待客戶端的響應，其執行速度可以接近於優化後的效能水平。

新增反向代理伺服器還可以給你的 web 伺服器安裝帶來靈活性。比如，一個某種型別的伺服器已經超載了，那麼就可以輕鬆的新增另一個相同的伺服器；如果某個機器宕機了，也可以很容易替代一個新的。

因為反向代理帶來的靈活性，所以反向代理也是一些效能加速功能的必要前提，比如：

• 負載均衡 (參見 Tip #2) – 負載均衡執行在反向代理伺服器上，用來將流量均衡分配給一批應用。有了合適的負載均衡，你就可以新增應用伺服器而根本不用修改應用。
• 快取靜態檔案 (參見 Tip #3) – 直接讀取的檔案，比如圖片或者客戶端程式碼，可以儲存在反向代理伺服器，然後直接發給客戶端，這樣就可以提高速度、分擔應用伺服器的負載，可以讓應用執行的更快。
• 網站安全 – 反向代理伺服器可以提高網站安全性，以及快速的發現和響應攻擊，保證應用伺服器處於被保護狀態。

NGINX 軟體為用作反向代理伺服器而專門設計，也包含了上述的多種功能。NGINX 使用事件驅動的方式處理請求，這會比傳統的伺服器更加有效率。NGINX plus 添加了更多高階的反向代理特性，比如應用的健康度檢查，專門用來處理請求路由、高階緩衝和相關支援。

NGINX Worker Process helps increase application performance

Tip #2: 新增負載平衡

新增一個負載均衡伺服器 是一個相當簡單的用來提高效能和網站安全性的的方法。與其將核心 Web 伺服器變得越來越大和越來越強，不如使用負載均衡將流量分配到多個伺服器。即使程式寫的不好，或者在擴容方面有困難，僅是使用負載均衡伺服器就可以很好的提高使用者體驗。

負載均衡伺服器首先是一個反向代理伺服器（參見Tip #1）——它接受來自網際網路的流量，然後轉發請求給另一個伺服器。特別是負載均衡伺服器支援兩個或多個應用伺服器，使用分配演算法將請求轉發給不同伺服器。最簡單的負載均衡方法是輪轉法round robin，每個新的請求都會發給列表裡的下一個伺服器。其它的複製均衡方法包括將請求發給活動連線最少的伺服器。NGINX plus 擁有將特定使用者的會話分配給同一個伺服器的能力。

負載均衡可以很好的提高效能是因為它可以避免某個伺服器過載而另一些伺服器卻沒有需要處理的流量。它也可以簡單的擴充套件伺服器規模，因為你可以新增多個價格相對便宜的伺服器並且保證它們被充分利用了。

可以進行負載均衡的協議包括 HTTP、HTTPS、SPDY、HTTP/2、WebSocket、FastCGI、SCGI、uwsgi、 memcached 等，以及幾種其它的應用型別，包括基於 TCP 的應用和其它的第4層協議的程式。分析你的 web 應用來決定你要使用哪些以及哪些地方效能不足。

相同的伺服器或伺服器群可以被用來進行負載均衡，也可以用來處理其它的任務，如 SSL 末端伺服器，支援客戶端的 HTTP/1.x 和 HTTP/2 請求，以及快取靜態檔案。

NGINX 經常被用於進行負載均衡；要想了解更多的情況，可以下載我們的電子書《選擇軟體負載均衡器的五個理由》。你也可以從 《使用 NGINX 和 NGINX Plus 配置負載均衡，第一部分》中瞭解基本的配置指導，在 NGINX Plus 管理員指南中有完整的NGINX 負載均衡的文件。。我們的商業版本 NGINX Plus 支援更多優化了的負載均衡特性，如基於伺服器響應時間的載入路由和 Microsoft’s NTLM 協議上的負載均衡。

Tip #3: 快取靜態和動態的內容

快取可以通過加速內容的傳輸速度來提高 web 應用的效能。它可以採用以下幾種策略：當需要的時候預處理要傳輸的內容，儲存資料到速度更快的裝置，把資料儲存在距離客戶端更近的位置，或者將這幾種方法結合起來使用。

有兩種不同型別資料的緩衝：

• 靜態內容快取。不經常變化的檔案，比如影象(JPEG、PNG) 和程式碼(CSS,JavaScript)，可以儲存在外圍伺服器上，這樣就可以快速的從記憶體和磁碟上提取。
• 動態內容快取。很多 web 應用會針對每次網頁請求生成一個新的 HTML 頁面。在短時間內簡單的快取生成的 HTML 內容，就可以很好的減少要生成的內容的數量，而且這些頁面足夠新，可以滿足你的需要。

舉個例子，如果一個頁面每秒會被瀏覽10次，你將它快取 1 秒，90%請求的頁面都會直接從快取提取。如果你分開快取靜態內容，甚至新生成的頁面可能都是由這些快取構成的。

下面由是 web 應用發明的三種主要的快取技術：

• 縮短資料與使用者的網路距離。把一份內容的拷貝放的離使用者更近的節點來減少傳輸時間。
• 提高內容伺服器的速度。內容可以儲存在一個更快的伺服器上來減少提取檔案的時間。
• 從過載伺服器上移走資料。機器經常因為要完成某些其它的任務而造成某個任務的執行速度比測試結果要差。將資料快取在不同的機器上可以提高快取資源和非快取資源的效能，而這是因為主機沒有被過度使用。

對 web 應用的快取機制可以在 web 應用伺服器內部實現。首先，快取動態內容是用來減少應用伺服器載入動態內容的時間。其次，快取靜態內容（包括動態內容的臨時拷貝）是為了更進一步的分擔應用伺服器的負載。而且快取之後會從應用伺服器轉移到對使用者而言更快、更近的機器，從而減少應用伺服器的壓力，減少提取資料和傳輸資料的時間。

改進過的快取方案可以極大的提高應用的速度。對於大多數網頁來說，靜態資料，比如大影象檔案，構成了超過一半的內容。如果沒有快取，那麼這可能會花費幾秒的時間來提取和傳輸這類資料，但是採用了快取之後不到1秒就可以完成。

舉一個在實際中快取是如何使用的例子， NGINX 和 NGINX Plus 使用了兩條指令來設定快取機制：proxy_cache_path 和 proxy_cache。你可以指定快取的位置和大小、檔案在快取中儲存的最長時間和其它一些引數。使用第三條（而且是相當受歡迎的一條）指令 proxy_cache_use_stale，如果提供新鮮內容的伺服器忙碌或者掛掉了，你甚至可以讓快取提供較舊的內容，這樣客戶端就不會一無所得。從使用者的角度來看這可以很好的提高你的網站或者應用的可用時間。

NGINX plus 有個高階快取特性，包括對快取清除的支援和在儀表盤上顯示快取狀態資訊。

要想獲得更多關於 NGINX 的快取機制的資訊可以瀏覽 NGINX Plus 管理員指南中的《參考文件》和《NGINX 內容快取》。

注意：快取機制分佈於應用開發者、投資決策者以及實際的系統運維人員之間。本文提到的一些複雜的快取機制從 DevOps 的角度來看很具有價值，即對集應用開發者、架構師以及運維操作人員的功能為一體的工程師來說可以滿足它們對站點功能性、響應時間、安全性和商業結果（如完成的交易數）等需要。

Tip #4: 壓縮資料

壓縮是一個具有很大潛力的提高效能的加速方法。現在已經有一些針對照片（JPEG 和PNG）、視訊（MPEG-4）和音樂（MP3）等各類檔案精心設計和高壓縮率的標準。每一個標準都或多或少的減少了檔案的大小。

文字資料 —— 包括HTML（包含了純文字和 HTML 標籤），CSS 和程式碼，比如 Javascript —— 經常是未經壓縮就傳輸的。壓縮這類資料會在對應用程式效能的感覺上，特別是處於慢速或受限的行動網路的客戶端，產生更大的影響。

這是因為文字資料經常是使用者與網頁互動的有效資料，而多媒體資料可能更多的是起提供支援或者裝飾的作用。智慧的內容壓縮可以減少 HTML，Javascript，CSS和其它文字內容對頻寬的要求，通常可以減少 30% 甚至更多的頻寬和相應的頁面載入時間。

如果你使用 SSL，壓縮可以減少需要進行 SSL 編碼的的資料量，而這些編碼操作會佔用一些 CPU 時間而抵消了壓縮資料減少的時間。

壓縮文字資料的方法很多，舉個例子，在 HTTP/2 中，小說文字的壓縮模式就特別調整了頭部資料。另一個例子是可以在 NGINX 裡開啟使用 GZIP 壓縮。你在你的服務裡預先壓縮文字資料之後，你就可以直接使用 gzip_static 指令來處理壓縮過的 .gz 版本。

Tip #5: 優化 SSL/TLS

安全套接字（SSL) 協議和它的下一代版本傳輸層安全（TLS）協議正在被越來越多的網站採用。SSL/TLS 對從原始伺服器發往使用者的資料進行加密提高了網站的安全性。影響這個趨勢的部分原因是 Google 正在使用 SSL/TLS，這在搜尋引擎排名上是一個正面的影響因素。

儘管 SSL/TLS 越來越流行，但是使用加密對速度的影響也讓很多網站望而卻步。SSL/TLS 之所以讓網站變的更慢，原因有二：

1. 任何一個連線第一次連線時的握手過程都需要傳遞金鑰。而採用 HTTP/1.x 協議的瀏覽器在建立多個連線時會對每個連線重複上述操作。
2. 資料在傳輸過程中需要不斷的在伺服器端加密、在客戶端解密。

為了鼓勵使用 SSL/TLS，HTTP/2 和 SPDY（在下一章會描述）的作者設計了新的協議來讓瀏覽器只需要對一個瀏覽器會話使用一個連線。這會大大的減少上述第一個原因所浪費的時間。然而現在可以用來提高應用程式使用 SSL/TLS 傳輸資料的效能的方法不止這些。

web 伺服器有對應的機制優化 SSL/TLS 傳輸。舉個例子，NGINX 使用 OpenSSL 執行在普通的硬體上提供了接近專用硬體的傳輸效能。NGINX 的 SSL 效能 有詳細的文件，而且把對 SSL/TLS 資料進行加解密的時間和 CPU 佔用率降低了很多。

更進一步，參考這篇文章瞭解如何提高 SSL/TLS 效能的更多細節，可以總結為一下幾點：

• 會話緩衝。使用指令 ssl_session_cache 可以快取每個新的 SSL/TLS 連線使用的引數。
• 會話票據或者 ID。把 SSL/TLS 的資訊儲存在一個票據或者 ID 裡可以流暢的複用而不需要重新握手。
• OCSP 分割。通過快取 SSL/TLS 證書資訊來減少握手時間。

NGINX 和 NGINX Plus 可以被用作 SSL/TLS 服務端，用於處理客戶端流量的加密和解密，而同時以明文方式和其它伺服器進行通訊。要設定 NGINX 和 NGINX Plus 作為 SSL/TLS 服務端，參看 《HTTPS 連線》 和《加密的 TCP 連線》。

Tip #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 的情況下才能使用它。這就意味著支援 HTTP/2 的瀏覽器只有在網站使用了 SSL 並且伺服器接收 HTTP/2 流量的情況下才會啟用 HTTP/2。否則的話瀏覽器就會使用 HTTP/1.x 協議。

當你實現 SPDY 或者 HTTP/2 時，你不再需要那些常規的 HTTP 效能優化方案，比如按域分割、資源聚合，以及影象拼合。這些改變可以讓你的程式碼和部署變得更簡單和更易於管理。要了解 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 就支援它了。

經過一段時間，我們 NGINX 希望更多的站點完全啟用 SSL 並且向 HTTP/2 遷移。這將會提高安全性，同時也會找到並實現新的優化手段，簡化的程式碼表現的會更加優異。

Tip #7: 升級軟體版本

一個提高應用效能的簡單辦法是根據軟體的穩定性和效能的評價來選在你的軟體棧。進一步說，因為高效能元件的開發者更願意追求更高的效能和解決 bug ，所以值得使用最新版本的軟體。新版本往往更受開發者和使用者社群的關注。更新的版本往往會利用到新的編譯器優化，包括對新硬體的調優。

穩定的新版本通常比舊版本具有更好的相容性和更高的效能。一直進行軟體更新，可以非常簡單的保持軟體保持最佳的優化，解決掉 bug，以及提高安全性。

一直使用舊版軟體也會阻止你利用新的特性。比如上面說到的 HTTP/2，目前要求 OpenSSL 1.0.1。在2016 年中期開始將會要求1.0.2 ，而它是在2015年1月才釋出的。

NGINX 使用者可以開始遷移到 NGINX 最新的開源軟體 或者 NGINX Plus；它們都包含了最新的能力，如 socket 分割和執行緒池（見下文），這些都已經為效能優化過了。然後好好看看的你軟體棧，把它們升級到你能升級到的最新版本吧。

Tip #8: Linux 系統性能調優

Linux 是大多數 web 伺服器使用的作業系統，而且作為你的架構的基礎，Linux 顯然有不少提高效能的可能。預設情況下，很多 Linux 系統都被設定為使用很少的資源，以符合典型的桌面應用使用。這就意味著 web 應用需要一些微調才能達到最大效能。

這裡的 Linux 優化是專門針對 web 伺服器方面的。以 NGINX 為例，這裡有一些在加速 Linux 時需要強調的變化：

• 緩衝佇列。如果你有掛起的連線，那麼你應該考慮增加 net.core.somaxconn 的值，它代表了可以快取的連線的最大數量。如果連線限制太小，那麼你將會看到錯誤資訊，而你可以逐漸的增加這個引數直到錯誤資訊停止出現。
• 檔案描述符。NGINX 對一個連線使用最多2個檔案描述符。如果你的系統有很多連線請求，你可能就需要提高sys.fs.file_max ，以增加系統對檔案描述符數量整體的限制，這樣才能支援不斷增加的負載需求。
• 臨時埠。當使用代理時，NGINX 會為每個上游伺服器建立臨時埠。你可以設定net.ipv4.ip_local_port_range 來提高這些埠的範圍，增加可用的埠號。你也可以減少非活動的埠的超時判斷來重複使用埠，這可以通過 net.ipv4.tcp_fin_timeout 來設定，這可以快速的提高流量。

對於 NGINX 來說，可以查閱 《NGINX 效能調優指南》來學習如果優化你的 Linux 系統，這樣它就可以很好的適應大規模網路流量而不會超過工作極限。

Tip #9: web 伺服器效能調優

無論你是用哪種 web 伺服器，你都需要對它進行優化來提高效能。下面的推薦手段可以用於任何 web 伺服器，但是一些設定是針對 NGINX 的。關鍵的優化手段包括：

• 訪問日誌。不要把每個請求的日誌都直接寫回磁碟，你可以在記憶體將日誌快取起來然後批量寫回磁碟。對於NGINX 來說，給指令 access_log 新增引數 buffer=size 可以讓系統在快取滿了的情況下才把日誌寫到磁碟。如果你添加了引數flush=time ，那麼快取內容會每隔一段時間再寫回磁碟。
• 快取。快取會在記憶體中存放部分響應，直到滿了為止，這可以讓與客戶端的通訊更加高效。記憶體放不下的響應會寫回磁碟，而這就會降低效能。當 NGINX 啟用了快取機制後，你可以使用指令 proxy_buffer_size 和 proxy_buffers 來管理快取。
• 客戶端保活。保活連線可以減少開銷，特別是使用 SSL/TLS 時。對於 NGINX 來說，你可以從 keepalive_requests 的預設值 100 開始增加最大連線數，這樣一個客戶端就可以在一個指定的連線上請求多次，而且你也可以通過增加keepalive_timeout 的值來允許保活連線存活更長時間，這樣就可以讓後來的請求處理的更快速。
• 上游保活。上游的連線——即連線到應用伺服器、資料庫伺服器等機器的連線——同樣也會受益於連線保活。對於上游連線來說，你可以增加 keepalive，即每個工人程序的空閒保活連線個數。這就可以提高連線的複用次數，減少需要重新開啟全新連線的次數。更多關於保活連線的資訊可以參見這篇“ HTTP 保活連線和效能”。
• 限制。限制客戶端使用的資源可以提高效能和安全性。對於 NGINX 來說，指令 limit_conn 和 limit_conn_zone 限制了給定來源的連線數量，而 limit_rate 限制了頻寬。這些限制都可以阻止合法使用者扒取資源，同時也避免了攻擊。指令limit_req 和 limit_req_zone 限制了客戶端請求。對於上游伺服器來說，可以在 upstream 的配置塊裡的 server 指令使用 max_conns 引數來限制連線到上游伺服器的連線數。 這樣可以避免伺服器過載。關聯的 queue 指令會建立一個佇列來在連線數抵達 max_connS 限制時在指定長度的時間內儲存特定數量的請求。
• 工人程序。工人程序負責處理請求。NGINX 採用事件驅動模型和作業系統特定的機制來有效的將請求分發給不同的工人程序。這條建議推薦設定 worker_processes 為每個 CPU 一個 。worker_connections 的最大數（預設512）可以在大部分系統上根據需要增加，實驗性地找到最適合你的系統的值。
• 套接字分割。通常一個套接字監聽器會把新連線分配給所有工人程序。套接字分割會為每個工人程序建立一個套接字監聽器，這樣一來以當套接字監聽器可用時，核心就會將連線分配給它。這可以減少鎖競爭，並且提高多核系統的效能，要啟用套接字分隔需要在 listen 指令裡面加上 reuseport 引數。
• 執行緒池。計算機程序可能被一個單一的緩慢的操作所佔用。對於 web 伺服器軟體來說，磁碟訪問會影響很多更快的操作，比如計算或者在記憶體中拷貝。使用了執行緒池之後慢操作可以分配到不同的任務集，而主程序可以一直執行快速操作。當磁碟操作完成後結果會返回給主程序的迴圈。在 NGINX 裡有兩個操作——read() 系統呼叫和 sendfile() ——被分配到了執行緒池

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

技巧。當改變任何作業系統或支援服務的設定時，一次只改變一個引數然後測試效能。如果修改引起問題了，或者不能讓你的系統更快，那麼就改回去。

在《調優 NGINX 效能》裡可以看到更詳細的 NGINX 調優方法。

Tip #10: 監視系統活動來解決問題和瓶頸

在應用開發中要使得系統變得非常高效的關鍵是監視你的系統在現實世界執行的效能。你必須能通過特定的裝置和你的 web 基礎設施上監控程式活動。

監視活動是最積極的——它會告訴你發生了什麼，把問題留給你發現和最終解決掉。

監視可以發現幾種不同的問題。它們包括：

• 伺服器宕機。
• 伺服器出問題一直在丟失連線。
• 伺服器出現大量的快取未命中。
• 伺服器沒有傳送正確的內容。

應用的總體效能監控工具，比如 New Relic 和 Dynatrace，可以幫助你監控到從遠端載入網頁的時間，而 NGINX 可以幫助你監控到應用交付端。當你需要考慮為基礎設施新增容量以滿足流量需求時，應用效能資料可以告訴你你的優化措施的確起作用了。

為了幫助開發者快速的發現、解決問題，NGINX Plus 增加了應用感知健康度檢查 ——對重複出現的常規事件進行綜合分析並在問題出現時向你發出警告。NGINX Plus 同時提供會話過濾功能，這可以阻止當前任務完成之前接受新的連線，另一個功能是慢啟動，允許一個從錯誤恢復過來的伺服器追趕上負載均衡伺服器群的進度。當使用得當時，健康度檢查可以讓你在問題變得嚴重到影響使用者體驗前就發現它，而會話過濾和慢啟動可以讓你替換伺服器，並且這個過程不會對效能和正常執行時間產生負面影響。下圖就展示了內建的 NGINX Plus 模組實時活動監視的儀表盤，包括了伺服器群，TCP 連線和快取資訊等 Web 架構資訊。

Use real-time application performance monitoring tools to identify and resolve issues quickly

總結: 看看10倍效能提升的效果

這些效能提升方案對任何一個 web 應用都可用並且效果都很好，而實際效果取決於你的預算、你能花費的時間、目前實現方案的差距。所以你該如何對你自己的應用實現10倍效能提升？

為了指導你瞭解每種優化手段的潛在影響，這裡是上面詳述的每個優化方法的關鍵點，雖然你的情況肯定大不相同：

• 反向代理伺服器和負載均衡。沒有負載均衡或者負載均衡很差都會造成間歇的效能低谷。增加一個反向代理，比如 NGINX ，可以避免 web 應用程式在記憶體和磁碟之間波動。負載均衡可以將過載伺服器的任務轉移到空閒的伺服器，還可以輕鬆的進行擴容。這些改變都可以產生巨大的效能提升，很容易就可以比你現在的實現方案的最差效能提高10倍，對於總體效能來說可能提高的不多，但是也是有實質性的提升。
• 快取動態和靜態資料。如果你有一個負擔過重的 web 伺服器，那麼毫無疑問肯定是你的應用伺服器，只通過快取動態資料就可以在峰值時間提高10倍的效能。快取靜態檔案可以提高几倍的效能。
• 壓縮資料。使用媒體檔案壓縮格式，比如影象格式 JPEG，圖形格式 PNG，視訊格式 MPEG-4，音樂檔案格式 MP3 可以極大的提高效能。一旦這些都用上了，然後壓縮檔案資料可以將初始頁面載入速度提高兩倍。
• 優化 SSL/TLS。安全握手會對效能產生巨大的影響，對它們的優化可能會對初始響應產生2倍的提升，特別是對於大量文字的站點。優化 SSL/TLS 下媒體檔案只會產生很小的效能提升。
• 使用 HTTP/2 和 SPDY。當你使用了 SSL/TLS，這些協議就可以提高整個站點的效能。
• 對 Linux 和 web 伺服器軟體進行調優。比如優化快取機制，使用保活連線，分配時間敏感型任務到不同的執行緒池可以明顯的提高效能；舉個例子，執行緒池可以加速對磁碟敏感的任務近一個數量級。

我們希望你親自嘗試這些技術。我們希望知道你說取得的各種效能提升案例。請在下面評論欄分享你的結果或者在標籤 #NGINX 和 #webperf 下 tweet 你的故事。