Web 應用性能提高的 10 個建議

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

若是 Web 應用運行在一臺獨立的電腦上，性能問題的解決方案是顯而易見的：換一臺更快的電腦，裏面加上更多的處理器、內存、快速磁盤陣列等等。而後在這臺新電腦上運行 WordPress 服務、Node.js 應用、Java 應用等等，會比之前快不少。（若是應用須要訪問服務器，方案仍是很簡單：換兩臺更快的電腦，用更快速的鏈接把它們鏈接起來。）

但電腦速度可能不是問題所在。一般 Web 應用運行緩慢，是因爲電腦一直在不一樣的任務間切換：同成千上萬的客戶交互、訪問磁盤上的文件、執行應用代碼和其它的任務。應用服務器可能會由於下面這些問題而崩潰 —— 內存耗盡、把不少的數據從內存交換到磁盤上、以及不少請求都在等待一個相似磁盤 I/O 的單個任務。

你應該採用一種徹底不一樣的方式，而不是升級硬件：增長一個反向代理服務器來分擔這些任務。這臺反向代理服務器設置在運行應用的電腦以前，用來處理網絡流量。只有這臺反向代理服務器直接連到網絡上，它和應用服務器經過一個快速的內部網絡進行通訊。

利用這臺反向代理服務器，應用服務器就不用等着和 Web 應用的用戶進行交互，它能夠專一在創建網頁，並經過反向代理服務器把它們發送到網絡上。由於應用服務器沒必要再等待客戶的響應，因此能以最優的速度運行。

增長一臺反向代理服務器也增長了 Web 服務器的彈性。若是一臺服務器過載了，很容易增長另外一臺同類型的服務器。若是一臺服務器宕機，也很容易把它換掉。

由於反向代理服務器帶來的靈活性，它也成爲了不少其它性能提高方法的先決條件，好比：

負載均衡（查看 建議二）—— 反向代理服務器上運行一個負載均衡器，把流量平均分配給一堆應用服務器。因爲負載均衡器的引入，在增長應用服務器時能夠徹底不用修改應用程序。
緩存靜態文件（查看 建議三）—— 直接請求的文件，好比圖片或者代碼文件，能夠存在反向代理服務器上，並直接發送給客戶端，這樣能夠更快地提供服務，分擔了應用服務器的負載，可讓應用執行得更快。
保護網站 —— 反向代理服務器能夠設置較高的安全級別，經過監控進快速識別和響應攻擊，這樣就能夠把應用服務器保護起來。

NGINX 軟件是專門設計用作反向代理服務器的，具備上述這些附加功能。NGINX 利用事件驅動處理的方法，比其它傳統的服務器更加高效。NGINX Plus 增長了更多反向代理的高級功能和支持，包含應用程序健康檢查、特定請求路由和高級緩存等



建議2、增長一個負載均衡器

增長一個負載均衡器是一個相對簡單的改動，並且會大幅度地改善網站的性能和安全性。你能夠利用負載均衡器把業務分配給一些服務器，而不是建造一臺更大更強的 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 早期版本的標準安全協議。）

建議3、緩存靜態和動態內容

緩存經過更快地向客戶端提供內容來改善 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 不只僅是一種軟件的部署方法。 它經過一種全新的方式，來思考如何讓軟件的做者（開發部門）和運營者（運營部門）進行合做與協同。）

建議4、壓縮數據

壓縮是一個有巨大潛能的性能加速器。已經有不少精心設計和高效的壓縮標準，有針對圖像的（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 的壓縮文件（給客戶端）。

建議5、優化 SSL/TLS

加密套接字層（SSL）協議及其後繼者 —— 傳輸層安全（TLS）協議，被愈來愈多得的網站所採用。SSL/TLS 加密了服務器發送給用戶的數據，提高了網站的安全性。影響這一趨勢的部分緣由是，Google 如今提高了啓用 HTTPS 網站的搜索排名。

儘管 SSL/TLS 愈來愈廣泛，它們倒是影響許多網站性能的癥結所在。SSL/TLS 下降網站性能有兩個緣由：

每當打開一個新的鏈接，最初的握手都須要創建加密密鑰。瀏覽器使用 HTTP/1.x 和服務器創建多條鏈接，隨着服務器的增多，鏈接會成倍增長。
服務器上加密數據，客戶端解密數據，這些都是持續的開銷。

爲了鼓勵使用 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 還有特別的設定步驟。

建議6、實現 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。這會提高安全性，同時因爲找到和實現了新的優化方法，代碼會更加簡潔並且性能更好。

建議7、更新軟件版本

一個提高應用性能的簡單方法，就是爲軟件技術棧選擇穩定的、性能好的組件。此外，高質量組件的程序員願意加班追求性能的提高和儘快修正 bug，因此最好使用軟件最新的穩定版本。新的發佈會獲得程序員和用戶社區的更多關注。新版本還會利用最新的編譯器優化技術，包含對新硬件的優化。

穩定的新版本一般都兼容老版本，並且有更好的性能。若是你持續更新軟件，很容易享受到性能優化、bug 修正和安全報警等諸多好處。

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

NGINX 用戶可使用最新版本的 NGINX  開源軟件或者 NGINX Plus，新功能都包含其中，好比套接字切分和線程池（查看下面），並且性能還在持續優化中。接下來仔細查看技術棧的軟件，並儘量快地使用最新的版本。

建議8、優化 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 系統，以便能絕不費力地處理大量的網絡流量。

建議9、優化 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 的更多信息，請參考這篇文章。

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

開發和發佈高性能應用的關鍵，在於密切和實時地關注應用程序在現實狀況下的性能。你必須可以監控特定設備的活動和網站的基礎設施。

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

監控能夠抓到不一樣類型的問題。它們包含：

服務器宕機。
服務器不穩定，容易掉線。
服務器大機率出現緩衝失效。
服務器發送的內容不正確。

你可使用 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）。優化緩衝區、保持鏈接、將耗時的任務分散到一個獨立的線程池上都能大幅提高性能。好比線程池運用在對磁盤操做頻繁的任務上會帶來指數級的提速。