「技術架構」10個提升應用程式性能的倚天劍和屠龍刀

• 2019 年 10 月 8 日
• 筆記

提高web應用程式性能比以往任何時候都更加重要。在線經濟活動的份額正在增長;超過5%的發達國家的經濟現在是在互聯網上的(參見參考資料中的互聯網統計數據)。而我們這個始終在線、高度連接的現代世界意味著用戶的期望比以往任何時候都要高。如果您的站點沒有立即響應，或者您的應用程式不能立即工作，用戶將很快轉向您的競爭對手。

例如，亞馬遜近10年前的一項研究證明，即使在那時，頁面載入時間每減少100毫秒，收入也會增加1%。最近的另一項研究強調了這樣一個事實:超過一半的受訪網站所有者表示，由於應用程式性能不佳，他們失去了收入或客戶。

一個網站需要多快?每載入一個頁面一秒鐘，大約有4%的用戶會放棄它。頂級電子商務網站提供從1秒到3秒的首次互動時間，這提供了最高的轉化率。很明顯，web應用程式性能的風險很高，而且可能還會增加。

想要提高性能很容易，但實際看到結果卻很難。為了幫助你的旅程，這篇部落格文章為你提供了10個技巧，幫助你將網站性能提高10倍。這是一個系列文章的第一部分，詳細介紹了如何在一些經過良好測試的優化技術的幫助下，並在NGINX的支援下，提高應用程式的性能。本系列還概述了在此過程中可能獲得的安全性改進。

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

如果您的web應用程式在一台機器上運行，那麼性能問題的解決方案可能很明顯:使用一台更快的機器，擁有更多處理器、更多RAM、更快的磁碟陣列，等等。然後，新機器可以運行您的WordPress伺服器，Node.js應用程式，Java應用程式等，比以前更快。(如果您的應用程式訪問資料庫伺服器，解決方案可能看起來仍然很簡單:獲得兩台更快的機器，以及它們之間更快的連接。)

問題是，機器的速度可能不是問題所在。Web應用程式通常運行緩慢，因為電腦在不同類型的任務之間切換:在數千個連接上與用戶交互、從磁碟訪問文件、運行應用程式程式碼等等。應用程式伺服器可能會崩潰——耗盡記憶體、將記憶體塊交換到磁碟，並讓許多請求等待磁碟I/O等單個任務。

您可以採用完全不同的方法，而不是升級硬體:添加反向代理伺服器來卸載這些任務。反向代理伺服器位於運行應用程式的機器前面，處理Internet流量。只有反向代理伺服器直接連接到Internet;與應用伺服器的通訊是通過一個快速的內部網路進行的。

使用反向代理伺服器可以讓應用伺服器從等待用戶與web應用程式交互的過程中解放出來，並讓它集中精力構建頁面，以便反向代理伺服器通過Internet發送。不再需要等待客戶機響應的應用程式伺服器可以以接近優化基準測試的速度運行。

添加反向代理伺服器還可以增加web伺服器設置的靈活性。例如，如果一個給定類型的伺服器被重載，可以很容易地添加另一個相同類型的伺服器;如果伺服器宕機，可以很容易地替換它。

由於它提供的靈活性，反向代理伺服器也是許多其他性能提升功能的先決條件，比如:

• 負載平衡(參見技巧2)——負載平衡器運行在反向代理伺服器上，以便在多個應用伺服器之間均勻地共享流量。有了負載平衡器，您就可以添加應用程式伺服器，而不需要更改您的應用程式。
• 快取靜態文件(參見技巧3)——直接請求的文件，如影像文件或程式碼文件，可以存儲在反向代理伺服器上，並直接發送到客戶機，這樣可以更快地為資產提供服務，並卸載應用程式伺服器，從而使應用程式運行得更快。
• 保護您的站點——反向代理伺服器可以配置為高安全性，並進行監視，以便快速識別和響應攻擊，保護應用程式伺服器。

NGINX軟體是專門為用作反向代理伺服器而設計的，具有上面描述的附加功能。NGINX使用事件驅動的處理方法，這比傳統伺服器更有效。NGINX Plus添加了更高級的反向代理特性，比如應用程式健康檢查、特殊的請求路由、高級快取和支援。

技巧2 -添加一個負載平衡器

添加負載平衡器是一個相對容易的更改，它可以顯著提高站點的性能和安全性。不需要使核心web伺服器更大更強大，而是使用負載平衡器在多個伺服器之間分配流量。即使應用程式編寫得很差，或者存在伸縮性問題，負載平衡器也可以在不進行任何其他更改的情況下改善用戶體驗。

首先，負載均衡器是一個反向代理伺服器(請參閱技巧1)——它接收Internet流量並將請求轉發到另一台伺服器。訣竅在於負載均衡器支援兩個或多個應用程式伺服器，使用多種演算法在伺服器之間分割請求。最簡單的負載平衡方法是輪詢，將每個新請求發送到列表上的下一個伺服器。其他方法包括向活動連接最少的伺服器發送請求。NGINX Plus具有在同一伺服器上繼續給定用戶會話的功能，這稱為會話持久性。

負載平衡器可以極大地提高性能，因為當其他伺服器等待流量時，它們可以防止一個伺服器過載。它們還可以方便地擴展web伺服器的容量，因為您可以添加成本相對較低的伺服器，並確保它們將得到充分利用。

可以負載平衡的協議包括HTTP、HTTPS、SPDY、HTTP/2、WebSocket、FastCGI、SCGI、uwsgi、memcached，以及其他幾種應用程式類型，包括基於TCP的應用程式和其他第4層協議。分析您的web應用程式，以確定您使用的是哪種應用程式，以及在哪些地方性能比較差。

用於負載平衡的同一或多個伺服器還可以處理其他幾個任務，比如SSL終止、對HTTP/1的支援。客戶端使用x和HTTP/2，並快取靜態文件。

NGINX通常用於負載平衡。要了解更多，請下載我們的電子書，選擇軟體負載平衡器的五個理由。您可以使用NGINX和NGINX Plus獲得負載平衡的基本配置說明，第1部分以及NGINX Plus管理指南中的完整文檔。NGINX Plus是我們的商業產品，支援更專業的負載平衡特性，比如基於伺服器響應時間的負載路由，以及基於微軟NTLM協議的負載平衡能力。

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

通過更快地將內容交付給客戶機，快取提高了web應用程式的性能。快取可以包括幾種策略:在需要時對內容進行預處理以實現快速交付、將內容存儲在更快的設備上、將內容存儲在離客戶機更近的地方，或者組合使用。

有兩種不同類型的快取需要考慮:

• 靜態內容快取——不經常更改的文件，如影像文件(JPEG、PNG)和程式碼文件(CSS、JavaScript)，可以存儲在邊緣伺服器上，以便從記憶體或磁碟快速檢索。
• 快取動態內容——許多Web應用程式為每個頁面請求生成新的HTML。通過在短時間內快取生成的HTML的一個副本，您可以顯著減少必須生成的頁面總數，同時仍然交付足夠新鮮的內容來滿足您的需求。

例如，如果一個頁面每秒有10個視圖，而您將其快取1秒，那麼對該頁面的90%的請求將來自快取。如果單獨快取靜態內容，即使是新生成的頁面版本也可能主要由快取的內容組成。

快取web應用程式生成的內容有三種主要技術:

• 將內容移動到離用戶更近的地方——將內容的副本保持在離用戶更近的地方，可以減少其傳輸時間。
• 將內容移動到更快的機器上——內容可以保存在更快的機器上，以便更快地檢索。
• 將內容從過度使用的機器上移開——機器有時在特定任務上的運行速度比基準測試慢得多，因為它們忙於其他任務。在不同的機器上進行快取可以提高快取資源的性能，也可以提高非快取資源的性能，因為主機的過載更少。

web應用程式的快取可以從內部(web應用程式伺服器)到外部實現。首先，快取用於動態內容，以減少應用伺服器上的負載。然後，快取用於靜態內容(包括動態內容的臨時副本)，進一步卸載應用伺服器。然後快取將從應用伺服器轉移到速度更快和/或更接近用戶的機器上，從而減輕應用伺服器的負擔，減少檢索和傳輸時間。

改進的快取可以極大地加快應用程式的速度。對於許多web頁面，靜態數據(如大型影像文件)占內容的一半以上。在沒有快取的情況下，檢索和傳輸這樣的數據可能需要幾秒鐘，但是如果數據是本地快取的，那麼只需要幾秒鐘。

作為在實踐中如何使用快取的示例，NGINX和NGINX Plus使用兩個指令來設置快取:proxy_cache_path和proxy_cache。您可以指定快取位置和大小、快取中保存的最大時間文件以及其他參數。使用第三個(也是非常流行的)指令proxy_cache_use_陳腐，您甚至可以在提供新鮮內容的伺服器繁忙或宕機時直接使用快取來提供陳舊的內容，從而為客戶機提供一些內容，而不是什麼也沒有。從用戶的角度來看，這可能會極大地提高站點或應用程式的正常運行時間。

NGINX Plus具有高級快取功能，包括支援快取清除和在儀錶板上顯示快取狀態，以便實時監控活動。

有關NGINX快取的更多資訊，請參閱參考文檔和NGINX Plus管理指南。

注意:快取跨越了開發應用程式的人員、進行資本投資決策的人員和實時運行網路的人員之間的組織界線。複雜的快取策略(如這裡提到的那些)是DevOps透視圖價值的一個很好的例子，在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的方式。為每台伺服器建立多個連接。
• 在伺服器上加密數據和在客戶機上解密數據的持續開銷。

為了鼓勵使用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——這些資訊存儲在票證或ID中關於特定SSL/TLS會話的資訊，這樣就可以順利地重用連接，而不需要新的握手。
• 通過快取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是最近批准的基於SPDY的IETF標準。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/1.x進行通訊。

當您實現SPDY或HTTP/2時，您不再需要典型的HTTP性能優化，例如域分片、資源合併和影像spriting。這些更改使您的程式碼和部署更簡單、更容易管理。要了解更多關於HTTP/2帶來的變化，請閱讀我們的白皮書《Web應用程式開發人員的HTTP/2》。

作為支援這些協議的一個例子，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將需要於2015年1月發布的OpenSSL 1.0.2。

NGINX用戶可以從移動到最新版本的NGINX或NGINX Plus開始;它們包括新的功能，如套接字分片和執行緒池(請參閱技巧9)，並且都在不斷地進行性能調優。然後深入了解您的堆棧中的軟體，並儘可能地使用最新的版本。

技巧8 -調優Linux的性能

Linux是當今大多數web伺服器實現的底層作業系統，作為基礎設施的基礎，Linux代表著提高性能的重要機會。默認情況下，許多Linux系統都進行了保守的調優，以使用很少的資源並匹配典型的桌面工作負載。這意味著web應用程式用例至少需要一定程度的調優才能獲得最大的性能。

Linux優化是特定於web伺服器的。以NGINX為例，下面是一些你可以考慮的加速Linux的變化:

• 積壓隊列——如果您的連接似乎正在停滯，請考慮增加net.core。可以排隊等待NGINX注意的最大連接數。如果現有連接限制太小，您將看到錯誤消息，您可以逐漸增加此參數，直到錯誤消息停止。
• 文件描述符- NGINX為每個連接使用最多兩個文件描述符。如果您的系統正在提供大量連接，您可能需要增加sys.fs。file_max是文件描述符的系統範圍限制，nofile是用戶文件描述符的限制，以支援增加的負載。
• 臨時埠——當用作代理時，NGINX為每個上游伺服器創建臨時(「臨時」)埠。您可以增加由net.ipv4設置的埠值範圍。ip_local_port_range，以增加可用埠的數量。您還可以在網路.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指令來管理它。

• 客戶機keepalives—Keepalive連接可以減少開銷，特別是在使用SSL/TLS時。對於NGINX，您可以增加客戶機在給定連接上可以發出的keepalive_requests的最大數量(默認值為100)，您還可以增加keepalive_timeout以允許keepalive連接保持更長時間的打開狀態，從而加快後續請求的速度。
• 上游保持連接—上游連接—到應用程式伺服器、資料庫伺服器等的連接—也可以從保持連接中獲益。對於上游連接，您可以增加keepalive，即為每個工作進程保持打開狀態的空閑keepalive連接的數量。這允許增加連接重用，減少了打開全新連接的需要。有關更多資訊，請參考我們的部落格文章、HTTP Keepalive連接和Web性能。
• 限制——限制客戶端使用的資源可以提高性能和安全性。對於NGINX, limit_conn和limit_conn_zone指令限制來自給定源的連接數量，而limit_rate限制頻寬。這些設置可以阻止合法用戶「佔用」資源，還有助於防止攻擊。limit_req和limit_req_zone指令限制客戶機請求。對於到上游伺服器的連接，使用max_conns參數到上游配置塊中的伺服器指令。這將限制到上游伺服器的連接，防止過載。關聯的queue指令創建一個隊列，該隊列在達到max_conns限制之後，在指定的時間長度內保存指定數量的請求。
• 工作進程——工作進程負責處理請求。NGINX使用基於事件的模型和依賴於作業系統的機制來有效地在工作進程之間分發請求。建議將worker_processes的值設置為每個CPU一個。如果需要，可以在大多數系統上安全地啟動worker_connections的最大數量(默認為512);嘗試找出最適合您的系統的值。
• 套接字分片——通常，一個套接字偵聽器將新連接分配給所有工作進程。套接字分片為每個工作進程創建套接字偵聽器，內核在套接字偵聽器可用時將連接分配給它們。這可以減少鎖爭用，提高多核系統的性能。要啟用套接字分片，請在listen指令上包含reuseport參數。
• 執行緒池——任何電腦進程都可以通過一個緩慢的操作來阻塞。對於web伺服器軟體，磁碟訪問可以支援許多更快的操作，比如在記憶體中計算或複製資訊。當使用執行緒池時，慢操作被分配給一組單獨的任務，而主處理循環繼續運行更快的操作。當磁碟操作完成時，結果返回到主處理循環。在NGINX中，兩個操作——read()系統調用和sendfile()——被卸載到執行緒池。

小費。當更改任何作業系統或支援服務的設置時，每次更改一個設置，然後測試性能。如果更改導致問題，或者沒有使站點運行得更快，請將其更改回來。

有關優化NGINX web伺服器的更多資訊，請參閱我們的部落格文章「優化NGINX以獲得性能」。

技巧10 -監控活動以解決問題和瓶頸

應用程式開發和交付的高性能方法的關鍵是密切和實時地觀察應用程式的實際性能。您必須能夠監視特定設備內和跨web基礎設施的活動。

監控站點活動主要是被動的——它告訴您發生了什麼，然後讓您發現問題並修復它們。

監視可以捕獲幾種不同類型的問題。它們包括:

• 伺服器宕機。
• 伺服器正在中斷連接。
• 伺服器的快取丟失率很高。
• 伺服器沒有發送正確的內容。

像New Relic或Dynatrace這樣的全局應用程式性能監視工具可以幫助您從遠程位置監視頁面載入時間，而NGINX可以幫助您監視應用程式交付端。應用程式性能數據告訴您，什麼時候您的優化對用戶產生了真正的影響，以及什麼時候您需要考慮向基礎設施添加容量來維持流量。

為了幫助快速識別和解決問題，NGINX Plus添加了應用程式感知的健康檢查——經常重複的合成事務，用於提醒您注意問題。NGINX Plus還具有會話耗盡功能，在現有任務完成時停止新連接，啟動速度較慢，允許恢復的伺服器在負載平衡的組中加快速度。當有效使用時，健康檢查允許您在問題嚴重影響用戶體驗之前識別問題，而會話耗盡和啟動緩慢允許您替換伺服器，並確保流程不會對感知的性能或正常運行時間產生負面影響。圖中顯示了內建的NGINX Plus活動監視儀錶板，用於具有伺服器、TCP連接和快取的web基礎設施。

結論-性能提高10倍

任何一個web應用程式的性能改進都有很大的不同，實際的收益取決於您的預算、您可以投入的時間和現有實現中的差距。那麼，如何為自己的應用程式實現10倍的性能改進呢?

為了幫助您了解每種優化的潛在影響，這裡有一些關於上述每種技巧可能帶來的改進的提示，儘管您的經驗幾乎肯定會有所不同:

• 反向代理伺服器和負載平衡——沒有負載平衡，或者負載平衡不好，可能會導致性能非常差的情況。添加反向代理伺服器(如NGINX)可以防止web應用程式在記憶體和磁碟之間發生抖動。負載平衡可以將處理從過載的伺服器轉移到可用的伺服器，並使擴展變得容易。這些變化可以帶來顯著的性能改進，與當前實現中最糟糕的時刻相比，可以輕鬆實現10倍的性能改進，總體性能方面的成就雖小，但卻很可觀。
• 快取動態和靜態內容——如果您的web伺服器負擔過重，並且其性能是應用伺服器的兩倍，那麼僅通過快取動態內容就可以在峰值時間內提高10倍。靜態文件的快取也可以提高性能的個位數倍數。
• 壓縮數據——使用媒體文件壓縮，如照片的JPEG、圖形的PNG、電影的MPEG - 4和音樂文件的MP3，可以大大提高性能。一旦這些都被使用，那麼壓縮文本數據(程式碼和HTML)可以將初始頁面載入時間提高兩倍。
• 優化SSL/TLS——安全握手對性能有很大的影響，因此優化握手可以使初始響應能力提高2倍，特別是對於文本較多的站點。在SSL/TLS下優化媒體文件傳輸可能只會帶來很小的性能改進。
• 實現HTTP/2和SPDY——當與SSL/TLS一起使用時，這些協議可能會導致站點整體性能的增量改進。
• 調優Linux和web伺服器軟體(如NGINX)——諸如優化緩衝、使用keepalive連接和將耗費大量時間的任務卸載到單獨的執行緒池等修復可以顯著提高性能;例如，執行緒池可以將磁碟密集型任務的速度提高近一個數量級。

我們希望您親自嘗試這些技巧。我們希望聽到您能夠實現的應用程式性能改進。在下面的評論中分享你的結果，或者用#NGINX和#webperf的散列標籤發布你的故事!

互聯網統計資料

Resources for Internet Statistics

• Statista.com – Share of the internet economy in the gross domestic product in G‑20 countries in 2016
• Kissmetrics – How Loading Time Affects Your Bottom Line (infographic)
• Econsultancy – Site speed: case studies, tips and tools for improving your conversion rate

原文：https://www.nginx.com/blog/10-tips-for-10x-application-performance/

本文：https://pub.intelligentx.net/node/761