性能測試的簡單幾個概念

基本概念

　　開始前，先簡單介紹一下性能測試的幾個基本概念。

　　併發數

　　併發數是指在同一個時間點，同時請求服務的客戶數量。

　　好比你們常說的：『 個人網站能夠承受一萬併發。 』在一般狀況下指的是：若是同時有一萬名用戶訪問網站，全部人均可以正常得到服務。而不會有超時或鏈接拒絕狀況發生。

　　吞吐率

　　吞吐率指的是服務處理請求的效率，計算方式爲 （ 總處理請求數 / 總耗時 ）。

　　HTTP 服務的吞吐率一般以 RPS（Requests Per Second 請求數每秒）做爲單位。吞吐量越高，表明服務處理效率就越高。換句話說就是網站的性能越高。

　　注意：吞吐率和併發數是兩個徹底獨立的概念。拿銀行櫃檯來舉個例子，併發數指同時有多少人往銀行櫃檯涌來。吞吐率則指銀行櫃檯在一段時間內能夠服務多少我的。

　　可是在性能測試中，兩者之間一般會呈現出一種關聯關係。當併發數增大時，吞吐率一般也會隨之上升（ 多用戶發揮出並行處理優點） 。但在併發數超過某個邊界值後，吞吐率則會降低 （用戶過多，花在上下文切換的開銷急劇增大，又或者內存消耗過多） 。

　　響應時間

　　響應時間指的是用戶從發出請求到接收完響應之間的總耗時，它由網絡傳輸耗時、服務處理耗時等多個部分組成。一般以毫秒（ms）做爲單位。

　　與併發數的關係：通常來講，隨着併發數增大，單個用戶的響應時間一般會隨之增長。這很好理解，餐館吃飯的人越多，單個顧客等待的時間就越長。

　　與吞吐率的關係：更高的吞吐率一般意味着更低的響應時間。由於吞吐率是以 單位時間 內的請求處理能力來計算的。

　　平均響應時間與百分位響應時間

　　平均響應時間指的是全部請求平均花費的時間，若是有100個請求，其中 98 個耗時爲 1ms，其餘兩個爲 100ms。那麼平均響應時間爲 (98 * 1 + 2 * 100) / 100.0 = 2.98ms 。

　　百分位數（ Percentile - Wikipedia ）是一個統計學名詞。以響應時間爲例， 99% 的百分位響應時間 ，指的是 99% 的請求響應時間，都處在這個值如下。

　　拿上面的響應時間來講，其總體平均響應時間雖然爲 2.98ms，但 99% 的百分位響應時間倒是 100ms。

　　相對於平均響應時間來講，百分位響應時間一般更能反映服務的總體效率。現實世界中用的較多的是 98% 的百分位響應時間，好比 GitHub System Status 中就有一條 98TH PERC. WEB RESPONSE TIME 曲線。

　　準備工做

　　1. 挑選測試目標

　　一個網站一般有不少個不一樣的頁面和接口。若是要徹底模擬真實環境的訪問，就得爲各頁面設置不一樣的權重，同時訪問全部頁面。或者取巧一點，採用重放真實環境訪問記錄的方式。

　　進行總體性能測試比較複雜，這裏不打算介紹相關內容。 此次主要討論對單個頁面測試。

　　那麼，怎麼挑選測試的目標頁面呢？通常來講，那些用戶訪問較多的頁面一般是比較好的選擇，它們多是：

　　· 首頁/Landing Page ：一般是用戶第一個打開的頁面

　　· 關鍵行爲頁面 ：若是網站的主要功能是發放優惠券，那就測試發放優惠券的接口

　　· 活動頁面 ：新活動上線推廣前，理所應當應該進行性能測試

　　儘可能模擬真實的用戶狀況

　　舉個例子，若是你想壓測一個文章列表頁，那麼必定先要挑選一位擁有必定數量文章的用戶，而後使用其身份來進行測試。千萬不要用那些一篇文章沒有、或只有少數文章的測試帳號。那樣會產生失真的測試結果，讓你對服務能力產生過於樂觀的估計。

　　因此，在測試與用戶相關的動態內容時，請細心挑選用戶身份，儘可能反映絕大多數用戶的狀況。

　　別忘了關注邊界狀況

　　讓測試過程反映絕大多數用戶的狀況很重要，但也請別忘了那些邊界狀況。

　　好比，當用戶擁有 50 篇如下的文章時，你的文章列表頁面響應速度很是好，吞吐率很是高。那麼若是某個用戶擁有 1000 篇文章呢？列表頁的性能表現還能知足需求嗎？響應時間會不會呈指數級上升？這些都是你須要測試的。

　　牢記『木桶效應』，你的服務極可能會由於沒有處理好這些邊界狀況而崩潰。

　　2. 選擇測試工具

　　市面上開源的 HTTP 性能測試工具很是多，我使用過的就有 wrk 、 ab 、 vegeta 、 siege 等。全部工具都支持對單個地址進行測試，部分工具支持經過地址列表進行批量測試。

　　除了 ab 這種歷史比較悠久的工具，大部分現代壓測工具效率都很是高，因此挑選哪一個區別不大。像我就是 wrk 的粉絲。

　　3. 記錄關鍵信息

　　硬件配置對測試結果影響很是大。因此，在開始測試前，最好記錄下你的服務器硬件狀況，這包括 CPU、內存、網卡速度等等。若是有必要的話，那些關鍵的關聯服務 - 好比數據庫 - 的硬件配置也應該一併記錄下來。

　　除了硬件配置外，還應該記錄下與你的服務密切相關的其餘配置信息，好比：

　　· 服務 Worker 類型是什麼？線程、協程或是進程？開啓了多少個？

　　· 是否使用數據庫鏈接池

　　等等等等。當你對比多份測試結果時，這些配置信息就會派上用場。若是你還想分享測試結果給他人，那麼提供這些配置信息是必須的。

　　進行壓測

　　接下來就能夠開始具體的壓測過程了。通常來講，針對單頁面的壓測過程都是很是簡單的。你只須要提供少數幾個參數：併發數、持續時間、頁面地址，而後等待測試完成便可。以 wrk 爲例：

　　$ wrk --latency -c100 -t5 -d 10 http://localhost:8080/hello/piglei

　　# -c 100：使用 100 個併發數

　　# -t 5：開啓 5 個線程

　　# -d 10：持續 10 秒鐘

　　一份完整的測試報告，一般要覆蓋多個不一樣的併發數配置，好比 [10, 100, 256, 512, 1024, 2048] 等等。你最終的測試結果，須要體現出服務在不一樣併發數下的性能表現差別。

　　在壓測過程當中，還有幾個注意點：

　　1. 專機專用

　　執行測試工具的機器與測試目標服務所在的機器上，最好不要運行其餘無關的程序。這樣能夠最大程度減少對測試結果的影響。

　　2. 測試時間不要太短

　　緩存須要預熱，服務也須要一段時間來穩定下來。因此，測試時間不要過短，好比小於 30 秒鐘。太短的測試時間會影響結果的可靠性。

　　爲了讓測試結果更可靠，請讓每次測試時間至少超過一分鐘，好比 3-5 分鐘。

　　3. 不要讓測試機成爲瓶頸

　　如今的服務器配置愈來愈強大，頗有可能，你的目標服務處理能力還沒達到瓶頸。你的測試機就已經先不行了。因此，在測試過程當中，請一併關注你的測試機負載狀況。

　　若是發現由於測試機自身瓶頸致使測試結果不許確，請使用更好的機器，或嘗試同時使用多臺測試機。

　　4. 調整好系統參數

　　在開始壓測前，確保系統的最大文件描述符數量等參數已經被調優過，避免影響壓測過程。

查看壓測結果

　　如下是執行 wrk 後的輸出結果：

Running 10s test @ http://localhost:8080/hello/piglei 5 threads and 100 connections Thread Stats   Avg      Stdev     Max   +/- Stdev Latency   336.28ms  651.93ms   1.72s    81.42% Req/Sec   657.74    547.89     3.47k    72.81% Latency Distribution 50%   28.88ms 75%   38.64ms 90%    1.71s 99%    1.72s 33320 requests in 10.00s, 4.10MB read Requests/sec:   3331.92 Transfer/sec:    419.74KB

在一次壓測結果中，有不少有用的指標：

　　· 吞吐率 Requests/sec： 服務吞吐能力，也就是一秒鐘平均處理多少請求數。它一般是壓測結果中最重要的指標。

　　· 數據傳輸速率 Transfer/sec： 數據傳輸速率，壓測響應結果較大的頁面時，請尤爲注意該值有沒有達到網絡瓶頸。

　　· 響應時間 Latency： 有關響應時間有不少不一樣值，請不要只關注平均響應時間，更須要注意最小值、最大值、百分位值、標準差等等。

　　· 錯誤請求數： 當併發數太高，或服務處理能力不夠時。請求就能夠發生錯誤。你的服務能夠最多承受多少併發而不產生錯誤？這是須要重點關注的指標之一。

　　可能影響壓測結果的因素

　　1. HTTP 響應是否開啓 Gzip 壓縮

　　若是目標服務處在 Nginx 等支持 gzip 壓縮的服務後，而恰好請求響應體又比較大。那麼是否開啓壓縮會較大程度影響到壓測結果。每一個工具開啓壓縮的方式都不同，通常狀況下，你須要手動添加 Accept-Encoding: gzip, defalte 請求頭來開啓 Gzip 壓縮。

　　2. 測試機器與目標服務之間的網絡質量

　　測試機器和目標服務之間的網絡情況會很大程度影響壓測結果。因此，最好保證測試機與目標服務處在同一網段。同時關注壓測結果中的數據傳輸速度（Transfer/sec）是否接近網絡速率極限值。

　　3. 負載均衡器

　　若是你的目標服務前面有配置負載均衡器，那麼它可能會對測試結果產生影響。

　　好比，使用 Nginx 的 proxy_pass 配置的後端服務，極限 RPS 在幾千左右。若是後端服務的吞吐率很是高，那就須要考慮負載均衡器會不會成爲你測試的瓶頸所在。

　　4. 是否開啓了 HTTP 長鏈接

　　較現代的 HTTP 服務器基本都支持持久化鏈接（之前俗稱 keep-alive），在測試過程當中，請肯定你的測試工具與服務端是否都開啓了 HTTP 長鏈接選項。

　　由於每次壓測一般要產生很是屢次請求，客戶端的鏈接是否能夠複用對結果影響很是大。能夠的話，請將開啓或關閉長鏈接做爲兩種狀況分開測試。