隨着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方式運行命令共兩種方式，如下：
1、 jmeter –n –t /home/jeff/script/jmeter_test.jmx –l /home/jeff/result/test.jtl
2、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 還有很多內容，後面有機會再一一介紹，謝謝大家!
轉載地址：http://news.chinabyte.com/362/14016862.shtml