電子發(fā)燒友App
Web 應用性能優(yōu)化迫在眉睫。線上經(jīng)濟活動份額不斷增長，發(fā)達世界的互聯(lián)網(wǎng)經(jīng)濟已占經(jīng)濟總量的 5%?以上（請參見下文的互聯(lián)網(wǎng)統(tǒng)計數(shù)據(jù)來源）。在這個始終在線、超級互聯(lián)的現(xiàn)代世界，用戶的期望已經(jīng)今非昔比。如果您的網(wǎng)站沒有立即做出響應，或者如果您的應用無法毫不延遲地運行，用戶轉(zhuǎn)身就會投向您的競爭對手。
例如，Amazon 近 10 年前的一項研究證明，頁面加載時間每減少 100 毫秒，收入就會增加 1% —— 10 年前就已如此，更何況是現(xiàn)在。最近的另一項研究也強調(diào)指出，超過一半的受訪網(wǎng)站所有者表示他們由于應用性能不佳失去了收入或客戶。
一個網(wǎng)站到底多快才行？頁面加載每延長 1 秒鐘，就有大約 4% 的用戶走掉。主要電商網(wǎng)站的首次交互時間從 1 秒到 3 秒不等，這個區(qū)間的轉(zhuǎn)化率最高。Web 應用性能的重要性由此可見，并且可能還會與日俱增。
想要提高性能很容易，難的是怎么看到結(jié)果。為此，本文提出了幫您實現(xiàn) 10 倍網(wǎng)站性能提升的 10 個技巧。本文是一系列博文的開帖之作，詳細介紹了如何借助一些久經(jīng)考驗的優(yōu)化技術(shù)以及 NGINX 的一些支持提高應用性能。該系列還概括介紹了您可能因此而獲得的安全性方面的改進。
技巧 1
使用反向代理服務器加速并保護應用
如果您的 Web 應用在一臺機器上運行，那要提升其性能非常簡單：換一臺更快的機器、多加幾顆處理器、增加 RAM、換成高速磁盤陣列即可，這樣新機器就可以更快地運行 WordPress 服務器、Node.js 應用和 Java 應用了。（如果您的應用需要訪問數(shù)據(jù)庫服務器，解決辦法仍然很簡單：找兩臺更快的機器，用更快的網(wǎng)絡連起來就行了。）
問題是，機器的速度可能并不是問題所在。Web 應用通常運行很慢，因為計算機要在不同類型的任務之間切換：通過數(shù)千個連接與用戶交互、訪問磁盤文件、運行應用代碼等等。應用服務器可能會因此而崩潰 —— 內(nèi)存耗盡、將內(nèi)存塊交換到磁盤、讓許多請求等待一個任務（比如磁盤 I/O）等。
除了升級硬件之外，您還可以采用一種完全不同的方法：添加反向代理服務器來卸載一些任務。反向代理服務器位于運行應用的機器的前面，負責處理互聯(lián)網(wǎng)流量。只有反向代理服務器直接連接到互聯(lián)網(wǎng)，與應用服務器的通信是通過一個高速內(nèi)網(wǎng)進行的。
反向代理服務器可以讓應用服務器不必再等待用戶與 Web 應用的交互，而是專注于構(gòu)建頁面，剩下的發(fā)送任務則交由反向代理來執(zhí)行。由于無需等待客戶端響應，應用服務器可以以接近優(yōu)化基準測試所達到的速度運行。
添加反向代理服務器還可以增加 Web 服務器設置的靈活性。例如，如果執(zhí)行既定任務的服務器過載了，您可以輕松添加一臺同類型的服務器；如果一臺服務器宕機，那么替換它也不難。
鑒于這種靈活性，反向代理服務器往往也是許多其他性能優(yōu)化手段的先決條件，例如：
負載均衡（見技巧 2） ?
在反向代理服務器上運行負載均衡器，以便在多個應用服務器之間均勻地共享流量。借助負載均衡器，您無需更改應用即可添加應用服務器。
緩存靜態(tài)文件（見技巧 3） ?
直接請求的文件（如圖像文件或代碼文件）可以存儲在反向代理服務器上，并直接發(fā)送到客戶端，這樣不僅可以更快地提供資產(chǎn)，還能減輕應用服務器的負擔，進而加快應用運行速度。
保護站點安全
反向代理服務器可以配置為高安全性并進行監(jiān)控，以便快速識別和響應攻擊，保護應用服務器的安全。
NGINX 軟件一開始的設計定位就是具有上述附加功能的反向代理服務器。NGINX 采用了事件驅(qū)動型處理方法，因此比傳統(tǒng)服務器效率更高。NGINX Plus 增添了更多高級反向代理功能，比如應用健康檢查、特定請求的路由、高級緩存，并提供技術(shù)支持。
技巧 2
添加負載均衡器
添加負載均衡器相對簡單，但卻能顯著提升站點性能和安全性。您不需要升級核心 Web 服務器的硬件性能或規(guī)模，而是直接使用負載均衡器將流量分發(fā)到多臺服務器。即使應用寫得不好或者難以擴展，負載均衡器也可以在應用不做出任何更改的情況下改善用戶體驗。
負載均衡器首先是一個反向代理服務器（見技巧 1），負責接收互聯(lián)網(wǎng)流量并將請求轉(zhuǎn)發(fā)給其他服務器。這里的關(guān)鍵在于負載均衡服務器可以支持兩臺或更多應用服務器，使用您選擇的算法在不同的服務器間分配請求。最簡單的負載均衡方法是輪詢，其中每個新請求都會被發(fā)送到列表中的下一臺服務器。將請求發(fā)送到活動連接數(shù)最少的服務器也是常用的方法之一。NGINX Plus 還具有會話保持功能，即將當前用戶的多個會話保持在同一臺服務器上。
負載均衡器可以避免出現(xiàn)一臺服務器過載而其他服務器過閑的情況，從而顯著提性能。此外，Web 服務器擴容也會變得簡單，您可以添加相對便宜的服務器，并確保物盡其用。
可以進行負載均衡的協(xié)議包括 HTTP、HTTPS、SPDY、HTTP/2、WebSocket、FastCGI、SCGI、uwsgi、memcached 以及其他應用類型，包括了基于 TCP 的應用和其他四層協(xié)議。您應該分析您的 Web 應用，確定它的類型以及性能短板是什么。
用于負載均衡的一臺或若干臺服務器還可以同時處理其他任務，例如 SSL 終止、按客戶端來選擇HTTP/1.x?和 HTTP/2 的使用、靜態(tài)文件緩存等。
技巧 3
緩存靜態(tài)和動態(tài)內(nèi)容
緩存可以通過更快地向客戶端交付內(nèi)容來改善 Web 應用的性能。緩存可以運用多種策略：預處理內(nèi)容以便在需要時快速交付內(nèi)容、將內(nèi)容存儲在更快的設備上、將內(nèi)容存儲在靠近客戶端的地方等等，這些策略也可以組合運用。
緩存有兩種類型：
靜態(tài)內(nèi)容緩存
圖像文件 (JPEG、PNG) 和代碼文件 (CSS、JavaScript) 等不常更改的文件可以存儲在邊緣服務器上，以便快速從內(nèi)存或磁盤中檢索。
動態(tài)內(nèi)容緩存
許多 Web 應用都會為每個頁面請求生成新的 HTML。通過短暫緩存一份生成的 HTML 副本，您可以大大減少必須要生成的頁面總數(shù)，同時仍然提供足夠滿足需求的新鮮內(nèi)容。
例如，假設一個頁面每秒被查看 10 次，那么緩存 1 秒就代表這個頁面有 90% 的請求來自緩存。如果您單獨緩存各個靜態(tài)內(nèi)容，那么即使是全新生成的頁面，也可能大部分來自緩存的內(nèi)容。
緩存 Web 應用生成的內(nèi)容主要會用到三種技術(shù)：
將內(nèi)容放到更靠近用戶的地方
離用戶越近，傳輸時間越少。
將內(nèi)容放到更快的機器上
機器越快，檢索越快。
將內(nèi)容從過度使用的機器上移除
在執(zhí)行某個特定任務時，機器的運行速度有時會比基準性能慢得多，因為它們忙于其他任務。在不同的機器上緩存可以提高緩存資源和非緩存資源的性能，因為主機過載較少。
Web 應用緩存可以由內(nèi)（Web 應用服務器）而外的實施。首先，緩存動態(tài)內(nèi)容，以減少應用服務器的負載。其次，緩存靜態(tài)內(nèi)容（包括動態(tài)內(nèi)容的臨時副本），以進一步減少應用服務器的負載。然后，將緩存從應用服務器轉(zhuǎn)移到更快和/或更靠近用戶的機器上，從而減輕應用服務器的負擔，縮短檢索和傳輸時間。
優(yōu)化的緩存可以極大地加快應用速度。對于很多網(wǎng)頁來說，靜態(tài)數(shù)據(jù)（例如大圖像文件）往往占據(jù)一半以上的內(nèi)容。如果不緩存，檢索和傳輸此類數(shù)據(jù)可能會花好幾秒鐘，但是如果將數(shù)據(jù)緩存在本地，可能只花幾分之一秒。
對于緩存的實踐應用，我們可以看這樣一個例子：NGINX 和 NGINX Plus 使用兩個指令來設置緩存：proxy_cache_path?和 proxy_cache。您可以指定緩存的位置和大小、文件的最長緩存時間以及其他參數(shù)。
您甚至還可以使用指令 proxy_cache_use_stale（相當受歡迎），指示緩存在本應提供新鮮內(nèi)容的服務器太忙或停機時提供舊文件，畢竟對客戶端來說，有總比沒有強。這可能會極大地改善您的網(wǎng)站或應用的正常運行時間，給用戶樹立一種十分穩(wěn)定的形象。
NGINX Plus 具有高級緩存功能，包括支持緩存清除、在儀表盤上以可視化的形式顯示緩存狀態(tài)（以監(jiān)控實時活動）等。
有關(guān) NGINX 緩存的更多信息，請參見參考文檔和《NGINX Plus 管理員指南》。
注意：緩存跨越了應用開發(fā)人員、資本投資決策人員和實時網(wǎng)絡運營人員之間的組織界線。復雜的緩存策略（比如本文提到的這些）很好地體現(xiàn)了 DevOps 的價值，其中應用開發(fā)人員、架構(gòu)師和運營人員攜手合作，朝著保障網(wǎng)站功能、響應時間、安全和業(yè)務成效（比如完成的交易或銷售）的目標共同發(fā)力。
技巧 4
壓縮數(shù)據(jù)
壓縮是一個重要的、潛在的性能加速器。圖片（JPEG 和 PNG）、視頻 (MPEG-4） 和音樂 (MP3) 等文件都有著精心打造和非常高效的壓縮標準，其中任何一個標準都可以將文件縮小一個數(shù)量級甚至更多。
HTML（包括純文本和 HTML 標簽）、CSS 和代碼(如 JavaScript）等文本數(shù)據(jù)經(jīng)常在不壓縮的情況下進行傳輸。壓縮這些數(shù)據(jù)可能會對感知到的 Web 應用性能產(chǎn)生特別明顯的影響，尤其是對速度緩慢或移動連接受限的客戶端來說。
這是因為文本數(shù)據(jù)通常足以讓用戶與頁面進行交互，而多媒體數(shù)據(jù)可能更多的體現(xiàn)支持性或錦上添花的作用。智能內(nèi)容壓縮通常可以將 HTML、Javascript、CSS 和其他文本內(nèi)容的帶寬需求減少 30% 及以上，并相應地減少加載時間。
如果使用 SSL，壓縮可以減少必須進行 SSL 編碼的數(shù)據(jù)量，從而抵消壓縮數(shù)據(jù)所需的一些 CPU 時間。
壓縮文本數(shù)據(jù)的方法有很多。例如，技巧 6?中就提到了一種在 SPDY 和 HTTP/2 中壓縮文本的新穎機制，該機制專門針對請求頭數(shù)據(jù)進行了調(diào)整。還有一個文本壓縮的例子，那就是您可以在 NGINX 中啟用 GZIP?壓縮功能。在服務中預壓縮文本數(shù)據(jù)之后，您可以使用 gzip_static?指令直接提供壓縮的 .gz?文件。
技巧 5
優(yōu)化 SSL/TLS
安全套接字層 (SSL) 協(xié)議及其升級版?zhèn)鬏攲影踩?(TLS) 協(xié)議在網(wǎng)站中的應用越來越廣泛。SSL/TLS 通過加密從源服務器傳輸給用戶的數(shù)據(jù)來提高站點安全性。Google 現(xiàn)在將 SSL/TLS 的使用作為搜索引擎排名的加分項，這在某種程度上加速了這一技術(shù)的普及。
雖然 SSL/TLS 變得越來越受歡迎，但它們帶來的相關(guān)性能問題也困擾著許多網(wǎng)站。SSL/TLS 拖慢網(wǎng)站的原因有兩個：
1.?每當打開新連接時，建立加密密鑰都需要進行初始握手。瀏覽器使用 HTTP/1.x?時對每臺服務器建立多個連接的方式加劇了這個問題。
2.?服務器端加密數(shù)據(jù)和客戶端解密數(shù)據(jù)也會帶來持續(xù)的開銷。
為了鼓勵人們使用 SSL/TLS，HTTP/2 和 SPDY 協(xié)議（見技巧 6）應運而生，這樣瀏覽器只需為每次會話建立一個連接便可，同時也搞定了 SSL 的一大開銷來源。但是，通過 SSL/TLS 交付的應用還有很大的性能提升空間。
SSL/TLS 的優(yōu)化機制因 Web 服務器而異。例如，NGINX 使用在標準商用硬件上運行的 OpenSSL?來提供與專用硬件解決方案相媲美的性能。NGINX 的 SSL 性能優(yōu)化是有據(jù)可查的，可以將執(zhí)行 SSL/TLS 加密和解密的時間及 CPU 消耗降到最低。
此外，本博文還詳細介紹了提升 SSL/TLS 性能的其他方式，簡而言之，這些技術(shù)是：
會話緩存
使用 ssl_session_cache?指令緩存保護每個 SSL/STL 新連接時使用的參數(shù)。
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
對于已經(jīng)使用 SSL/TLS 的站點，HTTP/2 和 SPDY 可能會讓性能更上一層樓，因為一個連接僅需要一次握手。對于尚未使用 SSL/TLS 的站點，HTTP/2 和 SPDY 從響應性的角度來看，轉(zhuǎn)向 SSL/TLS（通常會降低性能）是一種洗禮。
Google 在 2012 年推出了 SPDY，致力于在 HTTP/1.x?之上實現(xiàn)更快的速度。HTTP/2 是 IETF 最近批準的基于 SPDY 的標準。SPDY 得到了廣泛的支持，但很快就會被 HTTP/2 取代。
SPDY 和 HTTP/2 的關(guān)鍵功能是使用單個連接而非多個連接。單個連接是多路復用的，因此它可以同時承載多個請求和響應。
通過充分利用一個連接，這些協(xié)議避免了設置和管理多個連接（瀏覽器實施 HTTP/1.x?的必要條件）的開銷。使用單個連接對 SSL 尤為有用，因為這可以將 SSL/TLS 建立安全連接所需的握手時間降到最少。
SPDY 協(xié)議要求使用 SSL/TLS；HTTP/2 沒有對此作出正式要求，但目前所有支持 HTTP/2 的瀏覽器都只會在啟用 SSL/TLS 的情況下使用它。也就是說，只有當網(wǎng)站使用 SSL 且其服務器接受 HTTP/2 流量時，支持 HTTP/2 的瀏覽器才能使用 HTTP/2，否則瀏覽器將通過 HTTP/1.x?通信。
實施 SPDY 或 HTTP/2 后，就用不到域分片 (domain sharding)、資源合并、圖像拼合 (image spriting) 等典型的 HTTP 性能優(yōu)化技術(shù)了。這些變動也可以簡化代碼和部署的管理。如欲詳細了解 HTTP/2 帶來的變化，請參閱我們的白皮書：《面向 Web 應用開發(fā)人員的 HTTP/2》。
在對這些協(xié)議的支持方面，NGINX 從很早就開始支持 SPDY 了，并且現(xiàn)在使用 SPDY 的大多數(shù)站點都部署了 NGINX。NGINX 也是率先支持?HTTP/2 的開拓者之一，從 2015 年 9 月起，NGINX 開源版和 NGINX Plus 就引入了對 HTTP/2 的支持。
NGINX 希望隨著時間的推移，大多數(shù)站點都能完全啟用 SSL 并遷移到 HTTP/2。這不僅有助于提高安全性，而且隨著新型優(yōu)化技術(shù)的發(fā)現(xiàn)和實施，性能更高的代碼也將得到進一步簡化。
技巧 7
更新軟件版本
提高應用性能的一種簡單方法是根據(jù)穩(wěn)定性和性能為您的軟件棧選擇組件。此外，由于高質(zhì)量組件的開發(fā)人員可能會不斷增強性能和修復 bug，使用最新的穩(wěn)定版軟件是非常劃算的。新版本會受到開發(fā)人員和用戶社區(qū)的更多關(guān)注，同時也會利用新的編譯器優(yōu)化技術(shù)，包括對新硬件的調(diào)優(yōu)。
從兼容性和性能角度來看，新發(fā)布的穩(wěn)定版本通常也比舊版本更勝一籌。堅持軟件更新還可以讓您在調(diào)優(yōu)、bug 修復和安全警報方面保持優(yōu)勢。
使用舊版本會妨礙新功能使用。例如，上文提到的 HTTP/2 目前要求使用 OpenSSL 1.0.1.。從 2016 年年中開始，HTTP/2 會要求使用 OpenSSL 1.0.2（于 2015 年 1 月發(fā)布）。
NGINX 用戶可以先從升級到最新版的 NGINX?或 NGINX Plus?入手，它們具備套接字分片 (socket sharding) 和線程池（見技巧 9）等新功能，并且均會持續(xù)進行性能調(diào)優(yōu)。然后再深入檢查一下堆棧中的軟件，盡量遷移到最新版本。
技巧 8
優(yōu)化 Linux 性能
Linux 是當今大多數(shù) Web 服務器的底層操作系統(tǒng)。作為基礎架構(gòu)的基石，Linux 蘊藏著重大的調(diào)優(yōu)潛能。默認情況下，許多 Linux 系統(tǒng)的優(yōu)化都比較保守，以占用少量資源、滿足常規(guī)桌面工作負載為目標。這意味著在 Web 應用用例中，要想達到最高性能，調(diào)優(yōu)是必不可少的。
Linux 優(yōu)化因 Web 服務器而異。以 NGINX 為例，您可以重點考慮從以下幾個方面給 Linux 提速：
積壓隊列 (Backlog Queue)?
如果有一些連接得不到處理，可以考慮增大 net.core.somaxconn?的值，即等待 NGINX 處理的最大連接數(shù)。如果當前連接限制數(shù)太小，就會收到錯誤消息，您可以逐漸增加此參數(shù)，直到錯誤消息不再出現(xiàn)。
文件描述符
NGINX 最多對每個連接使用兩個文件描述符。如果系統(tǒng)服務于很多連接，則可能需要增大 sys.fs.file_max（整個系統(tǒng)范圍內(nèi)對文件描述符的限制）以及 nofile（用戶文件描述符限制），以支持增加的負載。
臨時端口
當用作代理時，NGINX 會為每個上游服務器創(chuàng)建臨時端口。您可以使用 net.ipv4.ip_local_port_range?拉寬端口的值閾，以增加可用端口的數(shù)量。您還可以使用 net.ipv4.tcp_fin_timeout?減少重用非活動端口之前的超時，從而加快周轉(zhuǎn)。
對于 NGINX，請參見《NGINX 性能調(diào)優(yōu)指南》，了解如何優(yōu)化您的 Linux 系統(tǒng)，使其輕松處理大量網(wǎng)絡流量！
技巧 9
優(yōu)化 Web 服務器的性能
無論您使用哪種 Web 服務器，都要對其進行調(diào)優(yōu)才能提升 Web 應用的性能。以下建議通常適用于任何 Web 服務器，其中包含一些針對 NGINX 的特定設置。主要的優(yōu)化技術(shù)有：
訪問日志
不要立即將每個請求的日志寫到磁盤，可以先將條目放到內(nèi)存緩沖區(qū)，然后再批量寫入。對于?NGINX，將?buffer=size?參數(shù)添加到?access_log?指令中，等內(nèi)存緩沖區(qū)寫滿后再把日志寫入磁盤。如果添加?flush=time?參數(shù)，緩沖區(qū)的內(nèi)容也會在指定的時間過后寫入磁盤。
緩沖
緩沖用于在內(nèi)存中保存一部分響應，直到緩沖區(qū)填滿為止，可以實現(xiàn)與客戶端更高效的通信。不適合寫入內(nèi)存的響應會被寫入磁盤，導致性能降低。啟用?NGINX?緩沖功能后，可以使用?proxy_buffer_size?和?proxy_buffers?指令進行管理。
客戶端?keepalive?連接
Keepalive?連接可以減少開銷，尤其是在使用?SSL/TLS?時。對于?NGINX，您可以增加客戶端通過現(xiàn)有連接發(fā)出的?keepalive_requests?的最大數(shù)量（默認值為?100），同時增大?keepalive_timeout?的值，讓?keepalive?連接保持更長時間的打開狀態(tài)，從而加快后續(xù)請求的速度。
Upstream keepalive?連接
Upstream?連接，即與應用服務器、數(shù)據(jù)庫服務器等服務器的連接，同樣可以從?keepalive?連接的設置中獲得好處。對于Upstream連接，您可以增加?keepalive，即為每個?worker?進程保持打開狀態(tài)的空閑?keepalive?連接的數(shù)量。這可以增加對連接的重復使用，減少打開全新連接的需求。有關(guān)更多信息，請參閱我們的博文：《HTTP Keepalive?連接和?Web?性能》。
限流
限制客戶端使用的資源可以提升性能和安全性。對于?NGINX，limit_conn?和?limit_conn_zone?指令可以限制來自既定源的連接數(shù)，limit_rate?則可以限制帶寬。這些設置可以防止合法用戶“侵吞”資源，也可以幫助防止攻擊。limit_req?和?limit_req_zone?指令能夠限制客戶端請求。對于到上游服務器的連接，您可以在?upstream?配置塊中使用?server?指令的?max_conns參數(shù)，以限制到上游服務器的連接，防止過載。關(guān)聯(lián)的?queue?指令會創(chuàng)建一個隊列，在達到?max_conns?限制后在指定的時間長度內(nèi)保存指定數(shù)量的請求。
Worker?進程
Worker?進程負責處理請求。NGINX?采用基于事件的模型和依賴操作系統(tǒng)的機制在?worker?進程之間高效地分發(fā)請求。建議將?worker_processes?的值設置為每個?CPU?一個。如果需要，大多數(shù)系統(tǒng)都支持提高?worker_connections?的最大數(shù)值（默認為?512），可以通過試驗找出最適合您的系統(tǒng)的值。
套接字分片?(Socket Sharding)
套接字監(jiān)聽器通常會向所有?worker?進程分發(fā)新連接。套接字分片?(Socket Sharding)?為每個?worker?進程創(chuàng)建一個套接字監(jiān)聽器，由內(nèi)核在套接字監(jiān)聽器可用時為其指定連接。這可以減少鎖爭用并提高多核系統(tǒng)的性能。要啟用套接字分片功能，請在?listen?指令中添加?reuseport參數(shù)。
線程池
任何計算機進程都可能會被一個緩慢的操作所拖累。對于 Web 服務器軟件，磁盤訪問可能阻礙很多較快的操作，例如內(nèi)存中的計算或信息復制。使用線程池時，慢操作會被分配給一組單獨的任務，而主處理循環(huán)仍然繼續(xù)運行較快的操作。磁盤操作完成后，結(jié)果會返回到主處理循環(huán)。NGINX 將 read()?系統(tǒng)調(diào)用和 sendfile()?這兩個操作卸載到了線程池。
小貼士：如果要更改任何操作系統(tǒng)或支持服務的設置，請一次先更改一項設置，然后測試性能。如果更改引發(fā)了問題或者不會加快網(wǎng)站運行速度，那就再改回去。
有關(guān) NGINX Web 服務器調(diào)優(yōu)的更多信息，請參見我們的博文：《優(yōu)化 NGINX 的性能》。
技巧 10
監(jiān)控實時活動，以解決問題和發(fā)現(xiàn)瓶頸
高效的應用開發(fā)和交付方法的關(guān)鍵在于實時密切監(jiān)控應用的真實性能。您必須要監(jiān)控特定設備和 Web 基礎架構(gòu)中的活動。
監(jiān)控站點活動多數(shù)時候是被動的 —— 它只告訴您發(fā)生了什么，至于如何發(fā)現(xiàn)和解決問題，則是我們自己的事情。
監(jiān)控可以捕獲以下幾種不同的問題：
服務器停機。
服務器運行不穩(wěn)定，導致連接中斷。
服務器出現(xiàn)大量緩存未命中問題。
服務器沒有發(fā)送正確的內(nèi)容。
全局應用性能監(jiān)控工具（例如 New Relic 或 Dynatrace）可幫助您遠程監(jiān)控頁面加載時間，NGINX 則可幫助您監(jiān)控應用交付這一端。應用性能數(shù)據(jù)可以顯示，您的優(yōu)化在什么情況下對用戶產(chǎn)生了真正的影響，以及什么情況下要為基礎架構(gòu)擴容以滿足流量需求。
為了幫助快速發(fā)現(xiàn)和解決問題，NGINX Plus 增加了應用感知型健康檢查功能，這類綜合事務（synthetic transaction）會定期重復，在發(fā)現(xiàn)問題后向您發(fā)出告警。NGINX Plus 還具有會話耗盡功能，能夠在現(xiàn)有任務完成時停止新連接，其慢啟動特性還允許恢復的服務器在負載均衡組內(nèi)逐漸升到正常水平。
只要使用得當，健康檢查就會幫助您及時發(fā)現(xiàn)問題，以免對用戶體驗造成重大影響，會話耗盡和慢啟動則允許您在不降低感知到的性能或正常運行時間的情況下替換服務器。下圖展示了 NGINX Plus 內(nèi)置了 Web 基礎架構(gòu)的實時活動監(jiān)控儀表盤，涵蓋了服務器、TCP 連接和緩存。
結(jié)論
實現(xiàn) 10 倍的性能提升
不同的 Web 應用有著不同的性能提升空間，實際的效果取決于您的預算、投入的時間以及當前實施的差距。那么，如何才能讓您的應用實現(xiàn) 10 倍的性能提升呢？
為了幫助您理解每種優(yōu)化技術(shù)的潛在影響，下面分條列出了文中所述的各項技巧可能帶來的一些改進，希望大家各取所需。
反向代理服務器及負載均衡
沒有負載均衡或者負載均衡不好可能會導致性能極低。添加反向代理服務器（例如?NGINX）可以防止?Web?應用在內(nèi)存和磁盤之間來回奔波。負載均衡可以將處理任務從過載的服務器轉(zhuǎn)移到可用的服務器，也可以簡化擴展。這些改變能夠顯著提升性能，與原有部署方式最差的時候相比，10?倍性能提升是很輕松的事，即使不到?10?倍也在總體上有了質(zhì)的飛躍。
緩存動態(tài)和靜態(tài)內(nèi)容
如果您的?Web?服務器同時又超負荷地充當應用服務器，那么僅緩存動態(tài)內(nèi)容就可以在高峰期達到?10?倍的性能提升，緩存靜態(tài)文件也可以實現(xiàn)幾倍的性能提升。
壓縮數(shù)據(jù)
使用?JPEG（照片）、PNG（圖形）、MPEG-4（電影）和?MP3（音樂文件）等媒體文件壓縮格式可以顯著提升性能。如果這些方式都用上了，那么壓縮文本數(shù)據(jù)（代碼和?HTML）可以將初始頁面加載速度提高兩倍。
優(yōu)化?SSL/TLS
安全握手對性能的影響很大，因此對其進行優(yōu)化可能會讓初次響應加快兩倍，尤其是對文本內(nèi)容較多的網(wǎng)站來說。如果是在?SSL/TLS?下優(yōu)化媒體文件傳輸，性能優(yōu)化的效果可能不是很大。
實施?HTTP/2?和?SPDY
當與?SSL/TLS?一起使用時，這些協(xié)議可能會對網(wǎng)站整體性能帶來增量改進。
Linux?和?Web?服務器軟件（如?NGINX）調(diào)優(yōu)
優(yōu)化緩沖、使用?keepalive?連接、將耗時的任務卸載到獨立的線程池等修復措施可以顯著提升性能，例如線程池可以將磁盤操作密集型任務的速度提高大約一個數(shù)量級。
我們希望大家多多嘗試這些技術(shù)，也期待聽到大家在改進應用性能方面的心得。
編輯：黃飛
?
工商網(wǎng)監(jiān)
評論