雲智慧壓測實戰分享之JMeter場景設置與監控

隨着IT技術的飛速發展和企業互聯網+業務規模不斷擴張，IT架構經歷了以數據計算爲核心的C/S架構、以聚焦業務功能及服務化構建應用的經典互聯網架構和現在整合IT資源和按需使用的雲計算架構三個階段。

與之同步發展的壓力測試一樣有三個發展階段，從防火牆內的壓力測試到基於雲計算的壓力測試，再到用戶視角的外部壓測，雲智慧的壓測寶就是第三代壓力測試產品。而Apache JMeter做爲一款大名鼎鼎的開源壓力測試產品，在設計之初就被用來測試C/S結構的軟件，其實現原理就是在防火牆內部產生壓力來進行壓測，測試目的也僅是對內網的系統硬件資源以及服務、數據庫在內網併發負載下的性能表現。

繼《雲智慧壓測實戰分享之JMeter工具使用初探》和《雲智慧壓測實戰分享之JMeter腳本錄製實例》兩篇內容以後，今天雲智慧工程師爲您帶來的是《雲智慧壓測實戰分享之JMeter場景設置與監控》，主要包含如下三部份內容：場景設置、場景運行和測試監聽。

場景設置：

測試場景是測試過程當中一般儘可能模擬真實系統環境及用戶操做而設計的場景，場景設計源於用戶的真實操做，設計原則是貼近於用戶實際操做，組合用戶的各類操做到場景中來。JMeter是經過線程組的設置來完成場景設置的，有些複雜場景還須要與邏輯控制器配合。
JMeter 線程組其實是創建一個線程池，JMeter根據用戶的設置進行線程池的初始化，及在運行時作各類異常處理。下面咱們用一幅圖看一下線程組的一些參數：

名稱：根據實際業務需求，最好有業務含義，與場景相符。
註釋：能夠隨意設置，能夠爲空，可是爲了之後方便使用，這裏最好寫上有意義的備註，和編程裏的註釋的目的是同樣。
在取樣器錯誤後要執行的的動做：就是線程組內某一個請求出錯後的異常處理方式
繼續：某一線程的某一請求出錯後，繼續運行，就是忽略本次錯誤繼續執行；
Start_NextThread loop:進行下一次線程循環，相似於for循環中的continue；
中止線程：當某一線程失敗或報錯後中止本線程，相似於LoadRunner中的中止該Vu；
中止測試：某一線程某一請求失敗後，中止全部線程，也就時中止本次測試，但不時當即中止測試，是在本場景中其餘線程執行迭代結束後，中止本次測試；
stop Test Now：立刻中止本次測試，無論其餘線程是否執行結束；
線程屬性：
線程數：能夠理解爲併發用戶數，一個線程對應一個併發用戶；與LoadRunner中的VU一致，只是LoadRunner中VU能夠是線程，也能夠是進程（以Http協議爲例）；
Ramp-up period(in second)：線程啓動開始運行的間隔時間，此處單位爲秒，即全部線程多長時間內所有啓動，假設線程設置爲100（模擬100vu併發），Ramp-up period設置爲10秒，那就是10秒內將100個線程啓動，至關於每秒中有10個線程啓動（100/10）；若是設置1，就是場景發起後1秒內所有啓動100個線程。
循環次數：「永遠」就是場景不結束就全部線程一直髮起壓測，若是想每一個線程迭代多少次以後就中止壓測，就能夠填入具體的數字。
Delay Thread creation until needed：選擇該項，線程在Ramp-up period的間隔時間啓動並運行，如100併發線程，10秒的ramp-up period時間，那麼1秒種啓動10個線程並運行採樣器中的請求。若是不勾選，測試計劃啓動全部線程（100個）爲new狀態，但不當即運行採樣器（sampler）中的請求，是按照ramp-up period時間來運行的，如100個線程，ramp-up 的時間是10秒，那麼每秒會有10個線程有new狀態轉爲Running，並執行採樣器中的請求。實際測試場景設置時，選不選該項都不會影響測試結果。兩者的區別是勾選線程是在間隔時間內創建啓動並運行，不勾選是先創建全部線程而後按間隔逐步執行。
調度器： 選擇調度器能夠控制場景執行時間或指定那個時間段執行，如秒殺場景就能夠設置爲某日某點某分開始執行，某日某點某分結束，具體調度器中各個參數以下：
持續時間：表示腳本持續運行的時間，以秒爲單位，例如腳本模擬用戶持續不斷登陸1個小時，你能夠在文本框中填寫3600。若是在1小時之內，結束時間已經到達，它將會覆蓋結束時間，繼續執行。 
啓動延遲：表示腳本延遲啓動的時間，在點擊啓動後，若是啓動時間已經到達，可是尚未到啓動延遲的時間，那麼，啓動延遲將會覆蓋啓動時間，等到啓動延遲的時間到達後，再運行系統。例如你的測試場景須要再另一個場景結束後開始，上一個場景須要10分鐘後結束，那麼你能夠再啓動延遲中設置601秒，點擊啓動，就能夠在上一個場景結束後，開始本次測試場景； 
啓動時間：表示咱們腳本開始啓動的時間，當你不想當即啓動腳本測試，可是啓動腳本的時間不會再電腦旁的時候，你能夠設定一個啓動的時間，而後再運行那裏點擊啓動，系統將不會當即運行，而是會等到你填寫的時間纔開始運行。
結束時間：與啓動時間對應，表示腳本結束運行的時間。
注意：若是咱們須要用到調度器來設定持續時間，若是線程數不夠多到持續時間結束，咱們就必須將循環次數勾選爲永遠，若是線程組裏面有其餘的循環，咱們也需將該循環次數勾選爲永遠。

在雲智慧壓測寶中場景設置就簡單多了，選擇好腳本和測試數據後，設置併發用戶和場景運行時間及壓力發起方式，平行仍是坡度，壓測寶能自動計算每秒啓動多少VU併發，如上圖所示。
場景運行：
JMeter的場景運行方式分爲兩種，一種是GUI可視化運行,測試者能夠實時看到壓測執行過程和壓測結果，像LoadRunner的Controller同樣；另一種是非GUI模式運行，即經過命令行像執行Shell同樣，在命令窗口運行。
JMeter的場景運行能夠在本地運行（即單機運行），也能夠是遠程運行，不管是GUI模式仍是非GUI模式都支持本地和遠程執行。本機運行相似於LoadRunner中將本機作爲Controller同時也做爲Agent；遠程執行相似於LoadRunner中將Agent安裝在別的機器上。
一般在須要大壓力的場景下，一臺機器產生的壓力不能知足測試需求，就須要多臺壓力機，這時就須要遠程執行，以下圖所示：

GUI運行：GUI方式是可視化，直接經過點擊鼠標就能夠控制場景的啓動和中止，同時也能隨時查看場景的運行情況，實時結果，測試線程數等。
1.本地運行的全部請求從一臺機器發出，以下圖，設置了4個併發線程：

運行的快捷菜單按鈕是：

，本地運行點擊按鈕開始運行，或者經過運行菜單開始運行，以下圖：

場景運行後，咱們能夠看到下圖中的狀態，時間00:00:01顯示的是當前場景運行的時長，後面感嘆號的圖標是當前場景中是否有線程異常，0爲沒有線程異常，0/4中前面表明當前運行的線程數，後面的4表明共運行了4個線程。
，

在場景運行過程當中點擊，能夠中止當前場景。
遠程執行：
遠程執行一般是在一臺機器上的JMeter做爲Controller，遠程的多臺機器（slave）做爲負載生成器，JMeter控制檯與負載機的通訊是經過RMI方式來完成的。在負載機上運行Agent程序，首先啓動jmeter-server，在JMeter控制機（Master）上點擊啓動遠程控制機。
說到這裏須要補充說明一下，在啓動遠程機以前須要在JMeter控制機上配置jmeter.properties文件，將遠程負載機IP地址配置到控制檯jmeter.properties文件中；以下圖所示，將遠程負載機的IP地址配置在Remote_hosts=配置項後面，多臺機器用逗號間隔，若是沒有制定端口的話，默認不配置端口。

注意：遠程運行方式若是腳本有依賴的參數文件或Jar包等文件，須要先把這些文件拷貝到遠程機負載機上，這點不是很人性化，雲智慧的壓測寶就不存在這樣的問題，只要把參數傳上就能夠了。
非GUI方式運行：
非GUI方式是沒有JMeter圖形化界面，在命令行窗口經過命令來運行場景，之因此用非GUI方式運行，是由於JMeter可視化界面及監聽器動態展現結果都比較消耗負載機的資源，在大併發下GUI方式每每會致使負載機資源緊張，對性能測試結果形成影響。固然這個影響不是影響被測系統如致使響應時間變大，處理能力減少等，而是影響負載機負載壓力的產生，如非GUI方式能夠產生200TPS的負載，而GUI方式只能產生140TPS的負載。固然若是資源比較充足的狀況下，GUI方式更能直觀實時瞭解測試場景運行情況。至於用哪一種方式，我的認爲根據實際狀況選擇，資源不寬裕的狀況下選擇非GUI方式，資源充足的狀況下能夠用GUI方式。
非GUI方式運行命令共兩種方式，以下：
一、 jmeter –n –t /home/jeff/script/jmeter_test.jmx –l /home/jeff/result/test.jtl
二、java –jar /apache-jmeter-3.0/bin/ApacheJMeter.jar –n –t /home/jeff/script/jmeter_test.jmx –l /home/jeff/result/test.jtl
jmeter 非GUI方式下的各類命令行參數這裏不在細說，你們能夠根據幫助文檔按圖索驥。
測試監聽：
性能測試監控的主要任務是獲取運行狀態、收集測試結果，測試結果有事務的響應時間、吞吐率、服務器硬件資源性能（CPU、內存、DISK I/O、網絡等）指標及JVM使用狀況、數據庫性能狀態等，這些在JMeter中是監聽器負責監聽的工做。
JMeter監聽器比較多，以下圖所示：

長時間執行測試計劃使用的監聽器主要是Summary Report 或者aggregate Graph (聚合報告)，也是今天主要介紹的內容。Summary Report以表格的形式顯示採樣結果，若是不一樣採樣器（不一樣請求）使用相同的名字，那麼測試結果在Summary Report中會統計到同一行，因此在給採樣器命名時不要都爲空或取相同的名字，根據實際業務進行命名。這個相似於LoadRunner腳本中的事物，若是事物名稱一致，測試結果中不一樣腳本相同事物將被統計到一塊兒，以下圖所示：

Label：每一個 JMeter 的 element （例如 HTTP Request ）都有一個 Name 屬性，這裏顯示的就是 Name 屬性的值；

Samples：表示你此次測試中一共發出了多少個請求，個人測試計劃模擬 10 個用戶，每一個用戶迭代 10次，所以這裏顯示 100；

Average：平均響應時間 —— 默認狀況下是單個 Request 的平均響應時間，當使用了 Transaction Controller 時，也能夠以 Transaction 爲單位顯示平均響應時間；
Min： 最小響應時間 在測試場景中採樣器一次請求最小的響應時間；
Max： 最大響應時間 在測試場景中採樣器一次請求最大的響應時間；
Error%： 本次測試中出現錯誤的請求的數量 / 請求的總數；
Throughput： 吞吐量 —— 默認狀況下表示每秒完成的請求數（ Request per Second ）RPS或者是TPS。
上面字段基本上已經可以說明測試結果，固然測試者也能夠根據本身需求添加一些須要監控的參數，點擊config按鈕，彈出下圖中配置頁面：

提示：保存的監聽參數越多，對本機和負載機的IO產生的壓力越大，因此並非參數越多越好，夠用就能夠了。
Aggregate Graph(聚合報告)

在Aggregate Report中，會顯示一行數據，共有10個字段，Label、#Samples、Average、Min、Max、Error%的含義和Summary Report同樣，有差別的字段以下：
Median：中位數，也就是 50％ 用戶的響應時間；
90% Line：90％ 用戶的響應時間；
Throughput：吞吐量——默認狀況下表示每秒完成的請求數（Request per Second），當使用了 Transaction Controller 時，也能夠表示相似 LoadRunner 的TPS[Transaction per Second]；
KB/Sec：每秒從服務器端接收到的數據量，至關於LoadRunner中的Throughput/Sec；
經過上面的介紹，能夠看到Summary Report和Aggregate Graph(聚合報告)相似，只是 聚合報告更詳細一點。說了這麼可能是不是以爲jmeter的監聽器很複雜，因此仍是壓測寶更方便，不須要設置什麼監聽器，測試結果直接實時展示，以下圖所示：

好了，今天就分享到這裏，JMeter 還有不少內容，後面有機會再一一介紹，謝謝你們！