性能測試===Locust介紹

簡述性能測試

提起性能測試，可能移動APP的從業人員會感受比較混淆，由於在客戶端（Android、iOS）中也有性能測試專項，主要涉及的是APP的啓動時間、內存、包大小、幀率，流量等客戶端相關的指標。在本博客以前的文章中，也包含了一些客戶端性能測試的內容。須要說明的是，本文所講解的性能測試都是針對服務器端，尤指Web系統的，與移動APP的性能測試徹底是不一樣的領域。

那麼，什麼是服務端的性能測試呢？

先從你們都熟悉的功能測試提及吧。例如，咱們要測試一個搜索功能，那麼咱們測試時，就會輸入搜索關鍵詞，點擊搜索按鈕，而後再去查看搜索結果，看結果是否跟咱們輸入的搜索關鍵詞匹配，若是匹配則說明搜索功能實現正確。

那如何對該功能進行性能測試呢？

答案就是，N我的同時進行功能性操做的同時，在確保功能實現正確的前提下，考察服務端應用程序的各項性能指標，以及服務器硬件資源的使用狀況。

固然，這個答案比較簡單粗暴，可是它仍然包含了性能測試的基本特色：

• 以功能實現正確爲前提
• 一般有必定的併發用戶
• 重點考察服務器端在必定併發壓力下的性能指標

最後，再明確下性能測試的目的。一般，對服務器端應用程序開展性能測試，是爲了驗證軟件系統是否可以達到預期的性能指標，同時發現軟件系統中存在的性能瓶頸，從而實現優化系統的目的。

性能測試方法的核心

根據不一樣的測試目的，性能測試能夠分爲多種類型，常見的有以下幾類：

• 基準測試（Standard Testing）
• 負載測試（Load Testing）
• 壓力測試（Stress Testing）
• 疲勞強度測試

首先說下基準測試。基準測試指的是模擬單個用戶執行業務場景時，考察系統的性能指標。嚴格意義上來說，基準測試並不能算做性能測試範疇，它跟功能測試並無太大區別。差別在於，基準測試的目的更多地是關注業務功能的正確性，或者說驗證測試腳本的正確性，而後，將基準測試時採集獲得的系統性能指標，做爲基準測試結果，爲後續併發壓力測試的性能分析提供參考依據。

負載測試，主要指的是模擬系統在正常負載壓力場景下，考察系統的性能指標。這裏說的正常負載，主要是指用戶對系統能承受的最大業務負載量的指望值，即預計系統最大應該支持多大用戶的併發量。經過負載測試，目的是驗證系統是否能知足預期的業務壓力場景。

和負載測試的概念比較接近的是壓力測試。通俗地講，壓力測試是爲了發如今多大併發壓力下系統的性能會變得不可接受，或者出現性能拐點（崩潰）的狀況。在加壓策略上，壓力測試會對被測系統逐步加壓，在加壓的過程當中考察系統性能指標的走勢狀況，最終找出系統在出現性能拐點時的併發用戶數，也就是系統支持的最大併發用戶數。

最後再說下疲勞強度測試。其實疲勞強度測試的加壓策略跟負載測試也很接近，都是對系統模擬出系統能承受的最大業務負載量，差別在於，疲勞強度測試更關注系統在長時間運行狀況下系統性能指標的變化狀況，例如，系統在運行一段時間後，是否會出現事務處理失敗、響應時間增加、業務吞吐量下降、CPU/內存資源增加等問題。

經過對比能夠發現，不一樣的性能測試類型，其本質的差別仍是在加壓策略上，而採用何種加壓策略，就取決於咱們實際的測試目的，即指望經過性能測試發現什麼問題。明白了這一點，性能測試類型的差別也就再也不容易混淆了。

結論要點1：性能測試手段的重點在於加壓的方式和策略。

性能瓶頸定位的核心

在前面頻繁地提到了性能指標，那性能指標究竟有哪些，咱們在性能測試的過程當中須要重點關注哪些指標項呢？

從維度上劃分，性能指標主要分爲兩大類，分別是業務性能指標和系統資源性能指標。

業務性能指標能夠直觀地反映被測系統的實際性能情況，經常使用的指標項有：

• 併發用戶數
• 事務吞吐率（TPS/RPS）
• 事務平均響應時間
• 事務成功率

而系統資源性能指標，主要是反映整個系統環境的硬件資源使用狀況，經常使用的指標包括：

• 服務器：CPU利用率、處理器隊列長度、內存利用率、內存交換頁面數、磁盤IO狀態、網卡帶寬使用狀況等；
• 數據庫：數據庫鏈接數、數據庫讀寫響應時長、數據庫讀寫吞吐量等；
• 網絡：網絡吞吐量、網絡帶寬、網絡緩衝池大小；
• 緩存（Redis）：靜態資源緩存命中率、動態數據緩存命中率、緩存吞吐量等；
• 測試設備（壓力發生器）：CPU利用率、處理器隊列長度、內存利用率、內存交換頁面數、磁盤IO狀態、網卡帶寬使用狀況等。

對於以上指標的具體含義我就不在此進行逐一說明了，你們能夠自行搜索，務必須要搞清楚每一個指標的概念及其意義。可能有些指標在不一樣的操做系統中的名稱有些差別，可是基本都會有對應的指標，其表明的意義也是相通的。例如，處理器隊列長度這個指標，在Windows中的指標名稱是System\Processor Queue Length，而在Linux系統中則須要看load averages。

可能對於最後一項（測試設備）有些人不大理解，監控被測系統環境的相關硬件資源使用狀況不就行了麼，爲何還要關注測試設備自己呢？這是由於測試設備在模擬高併發請求的過程當中，設備自己也會存在較高的資源消耗，例如CPU、內存、網卡帶寬吃滿，磁盤IO讀寫頻繁，處理器排隊嚴重等；當出現這類狀況後，測試設備自己就會出現瓶頸，沒法產生預期的併發壓力，從而咱們測試獲得的數據也就不具備可參考性了。此處暫不進行展開，後面我會再結合實際案例，經過圖表和數據對此詳細進行說明。

須要說明的是，性能指標之間一般都是有密切關聯的，單純地看某個指標每每很難定位出性能瓶頸，這須要咱們對各項性能指標的含義瞭然於胸，而後才能在實際測試的過程當中對系統性能情況綜合進行分析，找出整個系統真正的瓶頸。舉個簡單的例子，壓力測試時發現服務器端CPU利用率很是高，那這個能說明什麼問題呢？是服務端應用程序的算法問題，仍是服務器硬件資源配置跟不上呢？光看這一個指標並不能定位出產生問題的真正緣由，而若是僅由於這一點，就決定直接去優化程序算法或者升級服務器配置，最後也很難真正地解決問題。

結論要點2：性能瓶頸定位的重點在於性能指標的監控和分析。

引入性能測試工具

經過前面的講解，咱們已經知道性能測試的主要手段是經過產生模擬真實業務的壓力對被測系統進行加壓，與此同時監控被測系統的各項性能指標，研究被測系統在不一樣壓力狀況下的表現，找出其潛在的性能瓶頸。

那麼，如何對系統進行加壓，又如何對系統的指標進行監控呢？這裏，就須要引入性能測試工具了。

固然，咱們也能夠先看下在不借助性能測試工具的狀況下，如何手工地對系統進行性能測試。

假設如今咱們要對前面提到的搜索功能進行負載測試，驗證在20個併發用戶下搜索功能的事務平均響應時間是否在3秒之內。

很天然地，咱們能夠想到測試的必要條件有以下幾點：

• 20個測試人員，產生業務壓力
• 1個指揮人員，對20我的員的協調控制，實現併發操做
• 1個結果記錄人員，對每個人員的操做耗時進行監控和記錄
• 若干資源監控人員，實時查看被測系統的各項性能指標，對指標進行彙總、分析
• 1個結果統計人員，對20個用戶各操做消耗的時長進行彙總，計算其平均值

能夠看出，要經過人工來進行性能測試，操做上極爲繁瑣，須要投入的資源很是多，而這還僅僅是一個很是簡單的場景。設想，若是要測試10000併發，服務器有好幾十臺，顯然，這種狀況下是徹底不可能經過投入人力就能解決的。這也就是性能測試工具存在的必要性和誕生的背景。

性能測試工具的基本組成

當前，市面上已經有了不少性能測試工具，但無論是哪一款，基本都會包含以下幾個核心的模塊。

• 壓力生成器（Virtual User Generator）
• 結果採集器（Result Collector）
• 負載控制器（Controller）
• 系統資源監控器（Monitor）
• 結果分析器（Analysis）

原理結構圖以下所示：

對照前面手工進行性能測試的案例，不難理解，壓力發生器對應的是衆多測試人員，結果採集器對應的是結果記錄人員，負載控制器對應的是指揮人員，資源監控器對應的是若干資源監控人員，結果分析器對應的是結果統計人員。

其中，壓力發生器又是性能測試工具最核心的部分，它主要有兩個功能，一是真實模擬用戶操做，二是模擬有效併發。

然而，大多數性能測試工做人員可能都會忽略的是，當前市面上性能測試工具的壓力發生器基本都是存在缺陷的。

先說下模擬真實用戶操做。若是熟悉瀏覽器的工做原理，就會知道瀏覽器在加載網頁的時候，是同時併發多個TCP鏈接去請求頁面對應的HTTP資源，包括HTML、JS、圖片、CSS，當前流行的瀏覽器廣泛會併發6-10個鏈接。然而，性能測試工具在模擬單個用戶操做的時候，基本上都是單鏈接串行加載頁面資源。產生的差別在於，假如頁面有100個資源，每一個HTTP請求的響應時間約爲100毫秒，那麼瀏覽器採用6個鏈接並行加載網頁時大概會須要1.7秒（100/6*100毫秒），而測試工具採用單鏈接串行加載就須要10秒（100*100毫秒），二者結果相差十分巨大。這也解釋了爲何有時候咱們經過性能測試工具測試獲得的響應時間挺長，可是手動用瀏覽器加載網頁時感受挺快的緣由。

再說下有效併發。什麼叫有效併發？有效併發就是咱們在測試工具中設置了1000虛擬用戶數，實際在服務器端就能產生1000併發壓力。然而現實狀況是，不少時候因爲測試設備自身出現了性能瓶頸，壓力發生器產生的併發壓力遠小於設定值，而且一般測試工具也不會將該問題暴露給測試人員；若是測試人員忽略了這個問題，覺得測試獲得的結果就是在設定併發壓力下的結果，那麼最終分析得出的結論也就跟實際狀況截然不同了。不過，咱們能夠經過保障測試環境不存在瓶頸，使得實際生成的併發壓力盡量地與設定值一致；另外一方面，咱們也能夠經過在測試過程當中監控Web層（例如Nginx）的鏈接數和請求數，查看實際達到服務器端的併發數是否跟咱們的設定值一致，以此來反推壓力發生器的壓力是否有效。

瞭解這些缺陷的意義在於，咱們能夠更清楚測試工具的原理，從而更準確地理解測試結果的真實含義。

性能測試工具推薦

通過充分的理論鋪墊，如今總算能夠進入正題，開始講解工具部分了。

在性能測試工具方面，我重點向你們推薦Locust這款開源工具。目前階段，該款工具在國內的知名度還很低，大多數測試人員可能以前都沒有接觸過。爲了便於理解，我先將Locust與LoadRunner、Jmeter這類大衆耳熟能詳的性能測試工具進行簡單對比。

\	LoadRunner	Jmeter	Locust
受權方式	商業收費	開源免費	開源免費
開發語言	C/Java	Java	Python
測試腳本形式	C/Java	GUI	Python
併發機制	進程/線程	線程	協程
單機併發能力	低	低	高
分佈式壓力	支持	支持	支持
資源監控	支持	不支持	不支持
報告與分析	完善	簡單圖表	簡單圖表
支持二次開發	不支持	支持	支持

經過對比，你們可能會疑惑，Locust也不怎麼樣嘛，資源監控也不支持，報告分析能力也這麼弱，那爲啥還要選擇它呢？

受權方式這個就不說了。雖然LoadRunner是商業軟件，價格極其昂貴，可是國內盜版橫行，別說我的，就算是大型互聯網公司，用正版的也沒幾個。

從功能特性的角度來說，LoadRunner是最全面的，用戶羣體也是最多的，相應的學習資料也最爲豐富。我的建議若是是新接觸性能測試，能夠先熟悉LoadRunner，藉此瞭解性能測試工具各個模塊的概念和功能，在此基礎上再轉到別的測試工具，也都比較好上手了。不過，LoadRunner只能在Windows平臺使用，而且併發效率比較低，單臺壓力機難以產生較高的併發能力，這也是如今我棄用該款工具的主要緣由。

一樣地，Jmeter的併發機制也是基於線程，併發效率存在一樣的問題；另外，Jmeter在腳本編寫和描述方面是基於GUI操做，我的感受操做比較繁瑣（這個因人而異），所以不是很喜歡。

那麼，我重點推薦的Locust有啥特別的地方呢？

若是從總體功能上來看的話，Locust的功能的確比較單薄。不過，做爲性能測試工具最核心的壓力發生器部分，倒是很是不錯的。拋開官方文檔的介紹，我的以爲最讚的有兩點。

首先是模擬用戶操做，也就是測試腳本描述方面。Locust採用Pure Python腳本描述，而且HTTP請求徹底基於Requests庫。用過Requests的都知道，這個庫很是簡潔易用，但功能十分強大，不少其它編程語言的HTTP庫都借鑑了它的思想和模式，若是將其評選爲最好用的HTTP庫之一（不限語言），應該也不會有太大的爭議。除了HTTP(S)協議，Locust也能夠測試其它任意協議的系統，只須要採用Python調用對應的庫進行請求描述便可。

另一點就是併發機制了。Locust的併發機制摒棄了進程和線程，採用協程（gevent）的機制。採用多線程來模擬多用戶時，線程數會隨着併發數的增長而增長，而線程之間的切換是須要佔用資源的，IO的阻塞和線程的sleep會不可避免的致使併發效率降低；正因如此，LoadRunner和Jmeter這類採用進程和線程的測試工具，都很難在單機上模擬出較高的併發壓力。而協程和線程的區別在於，協程避免了系統級資源調度，由此大幅提升了性能。正常狀況下，單臺普通配置的測試機能夠生產數千併發壓力，這是LoadRunner和Jmeter都沒法實現的。

有了一個不錯的引擎，外表裝飾簡陋點也都是能夠接受的了。不過雖然Locust功能單薄，特別是在性能指標監控和測試報告圖表方面比較缺失，可是Locust的代碼結構清晰，核心代碼量也只有幾百行，可擴展性也很是不錯。換言之，Locust的可玩性（hackable）極強，對於一個想深刻挖掘性能測試工具原理的人來講，Locust很是適合。

好了，Locust的介紹暫且到這兒，後續我會再對Locust的使用方法和二次開發進行詳細介紹，也算是彌補官方文檔的不足吧。