將Web應用性能提升十倍的10條建議

導讀	提升 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 服務器安裝帶來靈活性。好比，一個某種類型的服務器已經超載了，那麼就能夠輕鬆的添加另外一個相同的服務器；若是某個機器宕機了，也能夠很容易替代一個新的。

由於反向代理帶來的靈活性，因此反向代理也是一些性能加速功能的必要前提，好比：

1. 負載均衡 (參見 Tip #2) – 負載均衡運行在反向代理服務器上，用來將流量均衡分配給一批應用。有了合適的負載均衡，你就能夠添加應用服務器而根本不用修改應用。
2. 緩存靜態文件 (參見 Tip #3) – 直接讀取的文件，好比圖片或者客戶端代碼，能夠保存在反向代理服務器，而後直接發給客戶端，這樣就能夠提升速度、分擔應用服務器的負載，可讓應用運行的更快。
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/二、WebSocket、FastCGI、SCGI、uwsgi、 memcached 等，以及幾種其它的應用類型，包括基於 TCP 的應用和其它的第4層協議的程序。分析你的 web 應用來決定你要使用哪些以及哪些地方性能不足。

相同的服務器或服務器羣能夠被用來進行負載均衡，也能夠用來處理其它的任務，如 SSL 末端服務器，支持客戶端的 HTTP/1.x 和 HTTP/2 請求，以及緩存靜態文件。

Tip #3: 緩存靜態和動態的內容

緩存能夠經過加速內容的傳輸速度來提升 web 應用的性能。它能夠採用如下幾種策略：當須要的時候預處理要傳輸的內容，保存數據到速度更快的設備，把數據存儲在距離客戶端更近的位置，或者將這幾種方法結合起來使用。

有兩種不一樣類型數據的緩存：

1. 靜態內容緩存。不常常變化的文件，好比圖像(JPEG、PNG) 和代碼(CSS,JavaScript)，能夠保存在外圍服務器上，這樣就能夠快速的從內存和磁盤上提取。
2. 動態內容緩存。不少 web 應用會針對每次網頁請求生成一個新的 HTML 頁面。在短期內簡單的緩存生成的 HTML 內容，就能夠很好的減小要生成的內容的數量，並且這些頁面足夠新，能夠知足你的須要。

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

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

1. 縮短數據與用戶的網絡距離。把一分內容的拷貝放的離用戶更近的節點來減小傳輸時間。
2. 提升內容服務器的速度。內容能夠保存在一個更快的服務器上來減小提取文件的時間。
3. 從過載服務器上移走數據。機器常常由於要完成某些其它的任務而形成某個任務的執行速度比測試結果要差。將數據緩存在不一樣的機器上能夠提升緩存資源和非緩存資源的性能，而這是由於主機沒有被過分使用。

對 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 性能的更多細節，能夠總結爲一下幾點：

1. 會話緩衝。使用指令 ssl_session_cache 能夠緩存每一個新的 SSL/TLS 鏈接使用的參數。
2. 會話票據或者 ID。把 SSL/TLS 的信息保存在一個票據或者 ID 裏能夠流暢的複用而不須要從新握手。
3. OCSP 分割。經過緩存 SSL/TLS 證書信息來減小握手時間。

NGINX 和 NGINX Plus 能夠被用做 SSL/TLS 服務端，用於處理客戶端流量的加密和解密，而同時以明文方式和其它服務器進行通訊。

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 性能優化方案，好比按域分割、資源聚合，以及圖像拼合。這些改變可讓你的代碼和部署變得更簡單和更易於管理。

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 時須要強調的變化：

1. 緩衝隊列。若是你有掛起的鏈接，那麼你應該考慮增長 net.core.somaxconn 的值，它表明了能夠緩存的鏈接的最大數量。若是鏈接限制過小，那麼你將會看到錯誤信息，而你能夠逐漸的增長這個參數直到錯誤信息中止出現。
2. 文件描述符。NGINX 對一個鏈接使用最多2個文件描述符。若是你的系統有不少鏈接請求，你可能就須要提升sys.fs.file_max ，以增長系統對文件描述符數量總體的限制，這樣才能支持不斷增長的負載需求。
3. 臨時端口。當使用代理時，NGINX 會爲每一個上游服務器建立臨時端口。你能夠設置net.ipv4.ip_local_port_range 來提升這些端口的範圍，增長可用的端口號。你也能夠減小非活動的端口的超時判斷來重複使用端口，這能夠經過 net.ipv4.tcp_fin_timeout 來設置，這能夠快速的提升流量。

Tip #9: web 服務器性能調優

不管你是用哪一種 web 服務器，你都須要對它進行優化來提升性能。下面的推薦手段能夠用於任何 web 服務器，可是一些設置是針對 NGINX 的。關鍵的優化手段包括：

1. 訪問日誌。不要把每一個請求的日誌都直接寫回磁盤，你能夠在內存將日誌緩存起來而後批量寫回磁盤。對於NGINX 來講，給指令 access_log 添加參數 buffer=size 可讓系統在緩存滿了的狀況下才把日誌寫到磁盤。若是你添加了參數flush=time ，那麼緩存內容會每隔一段時間再寫回磁盤。
2. 緩存。緩存會在內存中存放部分響應，直到滿了爲止，這可讓與客戶端的通訊更加高效。內存放不下的響應會寫回磁盤，而這就會下降效能。當 NGINX 啓用了緩存機制後，你可使用指令 proxy_buffer_size 和 proxy_buffers 來管理緩存。
3. 客戶端保活。保活鏈接能夠減小開銷，特別是使用 SSL/TLS 時。對於 NGINX 來講，你能夠從 keepalive_requests 的默認值 100 開始增長最大鏈接數，這樣一個客戶端就能夠在一個指定的鏈接上請求屢次，並且你也能夠經過增長keepalive_timeout 的值來容許保活鏈接存活更長時間，這樣就可讓後來的請求處理的更快速。
4. 上游保活。上游的鏈接——即鏈接到應用服務器、數據庫服務器等機器的鏈接——一樣也會受益於鏈接保活。對於上游鏈接來講，你能夠增長 keepalive，即每一個工人進程的空閒保活鏈接個數。這就能夠提升鏈接的複用次數，減小須要從新打開全新鏈接的次數。更多關於保活鏈接的信息能夠參見這篇「 HTTP 保活鏈接和性能」。
5. 限制。限制客戶端使用的資源能夠提升性能和安全性。對於 NGINX 來講，指令 limit_conn 和 limit_conn_zone 限制了給定來源的鏈接數量，而 limit_rate 限制了帶寬。這些限制均可以阻止合法用戶扒取資源，同時也避免了攻擊。指令limit_req 和 limit_req_zone 限制了客戶端請求。對於上游服務器來講，能夠在 upstream 的配置塊裏的 server 指令使用 max_conns 參數來限制鏈接到上游服務器的鏈接數。 這樣能夠避免服務器過載。關聯的 queue 指令會建立一個隊列來在鏈接數抵達 max_connS 限制時在指定長度的時間內保存特定數量的請求。
6. 工人進程。工人進程負責處理請求。NGINX 採用事件驅動模型和操做系統特定的機制來有效的將請求分發給不一樣的工人進程。這條建議推薦設置 worker_processes 爲每一個 CPU 一個 。worker_connections 的最大數（默認512）能夠在大部分系統上根據須要增長，實驗性地找到最適合你的系統的值。
7. 套接字分割。一般一個套接字監聽器會把新鏈接分配給全部工人進程。套接字分割會爲每一個工人進程建立一個套接字監聽器，這樣一來以當套接字監聽器可用時，內核就會將鏈接分配給它。這能夠減小鎖競爭，而且提升多核系統的性能，要啓用套接字分隔須要在 listen 指令裏面加上 reuseport 參數。
8. 線程池。計算機進程可能被一個單一的緩慢的操做所佔用。對於 web 服務器軟件來講，磁盤訪問會影響不少更快的操做，好比計算或者在內存中拷貝。使用了線程池以後慢操做能夠分配到不一樣的任務集，而主進程能夠一直運行快速操做。當磁盤操做完成後結果會返回給主進程的循環。在 NGINX 裏有兩個操做——read() 系統調用和 sendfile() ——被分配到了線程池

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

技巧。當改變任何操做系統或支持服務的設置時，一次只改變一個參數而後測試性能。若是修改引發問題了，或者不能讓你的系統更快，那麼就改回去。

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

在應用開發中要使得系統變得很是高效的關鍵是監視你的系統在現實世界運行的性能。你必須能經過特定的設備和你的 web 基礎設施上監控程序活動。

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

監視能夠發現幾種不一樣的問題。它們包括：

1. 服務器宕機。
2. 服務器出問題一直在丟失鏈接。
3. 服務器出現大量的緩存未命中。
4. 服務器沒有發送正確的內容。

應用的整體性能監控工具，好比 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倍性能提高？

爲了指導你瞭解每種優化手段的潛在影響，這裏是上i面詳述的每一個優化方法的關鍵點，雖然你的狀況確定大不相同：

1. 反向代理服務器和負載均衡。沒有負載均衡或者負載均衡不好都會形成間歇的性能低谷。增長一個反向代理，好比 NGINX ，能夠避免 web 應用程序在內存和磁盤之間波動。負載均衡能夠將過載服務器的任務轉移到空閒的服務器，還能夠輕鬆的進行擴容。這些改變均可以產生巨大的性能提高，很容易就能夠比你如今的實現方案的最差性能提升10倍，對於整體性能來講可能提升的很少，可是也是有實質性的提高。
2. 緩存動態和靜態數據。若是你有一個負擔太重的 web 服務器，那麼毫無疑問確定是你的應用服務器，只經過緩存動態數據就能夠在峯值時間提升10倍的性能。緩存靜態文件能夠提升幾倍的性能。
3. 壓縮數據。使用媒體文件壓縮格式，好比圖像格式 JPEG，圖形格式 PNG，視頻格式 MPEG-4，音樂文件格式 MP3 能夠極大的提升性能。一旦這些都用上了，而後壓縮文件數據能夠將初始頁面加載速度提升兩倍。
4. 優化 SSL/TLS。安全握手會對性能產生巨大的影響，對它們的優化可能會對初始響應產生2倍的提高，特別是對於大量文本的站點。優化 SSL/TLS 下媒體文件只會產生很小的性能提高。
5. 使用 HTTP/2 和 SPDY。當你使用了 SSL/TLS，這些協議就能夠提升整個站點的性能。
6. 對 Linux 和 web 服務器軟件進行調優。好比優化緩存機制，使用保活鏈接，分配時間敏感型任務到不一樣的線程池能夠明顯的提升性能；舉個例子，線程池能夠加速對磁盤敏感的任務近一個數量級。

咱們但願你親自嘗試這些技術。咱們但願知道你說取得的各類性能提高案例。

網上資源

1. Statista.com – Share of the internet economy in the gross domestic product in G-20 countries in 2016
2. Load Impact – How Bad Performance Impacts Ecommerce Sales
3. Kissmetrics – How Loading Time Affects Your Bottom Line (infographic)
4. Econsultancy – Site speed: case studies, tips and tools for improving your conversion rate
5. 《NGINX 內容緩存》
6. 《NGINX 性能調優指南》
7. 《NGINX Plus 管理員指南參考文檔》
8. 《HTTPS 鏈接》
9. 《加密的 TCP 鏈接》
10. 《HTTP/2 for Web ApplicationDevelopers 白皮書》

免費提供最新Linux技術教程書籍，爲開源技術愛好者努力作得更多更好：https://www.linuxprobe.com/