Jmeter你所不知道的技巧！Jmeter使用技巧集錦
JMeter是一個流行的用於負載測試的開源工具，具有許多有用的功能元件，如線程組（threadgroup），定時器（timer），和HTTP取樣(sampler)元件。本文是對JMeter用戶手冊的補充，而且提供了關於使用Jmeter的一些模擬元件開發質量測試腳本的指導。
本文同時也討論了一項重要的內容：在指定了精確的響應時間要求後，如何來校驗測試結果，筆者是在採用了置信區間分析這種嚴格的統計方式的情況下應如何操作。請注重，我假定本文的讀者們瞭解關於Jmeter的基礎知識，本文的例子基於Jmeter2。0。3版。
確定一個線程組的ramp-upperiod（Determine）
Jmeter腳本的第一個要素是線程組（ThreadGroup），因此首先讓我們往返顧一下。正如圖一所示，線程組需要設置以下參數：
·線程數量。
·ramp-upperiod。
·運行測試的次數。
·啟動時間:立即或者預定的時間，假如是後者，線程組所包含的元素也要指定這個起止時間。
圖1：JMeter線程組（JMeterThreadGroup）
每個線程均獨立運行測試計劃。因此，線程組常用來模擬並發用戶訪問。假如客戶機沒有足夠的能力來模擬較重的負載，可以使用Jmeter的分散式測試功能來通過一個Jmeter控制檯來遠程控制多個Jmeter引擎完成測試。
參數ramp-upperiod用於告知JMeter要在多長時間內建立全部的線程。默認值是0。假如未指定ramp-upperiod，也是說ramp-upperiod為零，JMeter將立即建立所有線程，假設ramp-upperiod設置成T秒，全部線程數設置成N個，JMeter將每隔T/N秒建立一個線程。
線程組的大部分參數是不言自明的，只有ramp-upperiod有些難以理解，因為如何設置適當的值並不輕易。首先，假如要使用大量線程的話，ramp-upperiod一般不要設置成零。因為假如設置成零，Jmeter將會在測試的開始建立全部線程並立即發送訪問請求，這樣一來很輕易使伺服器飽和，更重要的是會隱性地增加了負載，這意味著伺服器將可能過載，不是因為平均訪問率高而是因為所有線程的第一次並發訪問而引起的不正常的初始訪問峯值，可以通過Jmeter的聚合報告監聽器看到這種現象。
這種異常不是我們需要的，因此，確定一個合理的ramp-upperiod的規則是讓初始點擊率接近平均點擊率。當然，也許需要運行一些測試來確定合理訪問量。
基於同樣的原因，過大的ramp-upperiod也是不恰當的，因為將會降低訪問峯值的負載，換句話說，在一些線程還未啟動時，初期啟動的部分線程可能已經結束了。
那麼，如何檢驗ramp-upperiodI太小了或者太大了呢？首先，推測一下平均點擊率並用匯流排程除點擊率來計算初始的ramp-upperiod。例如，假設線程數為100，估計的點擊率為每秒10次，那麼估計的理想ramp-upperiod是100/10=10秒。那麼，應怎樣來提出一個合理的估算點擊率呢？沒有什麼好辦法，必須通過運行一次測試腳本來獲得。
其次，在測試計劃（testplan）中增加一個聚合報告監聽器，如圖2所示，其中包含了所有獨立的訪問請求（一個samplers）的平均點擊率。第一次取樣的點擊率（如http請求）與ramp-upperiod和線程數量密切相關。通過調整ramp-upperiod可以使首次取樣的奠基率接近平均取樣的點擊率。
圖2：JMeter聚合報告
第三，查驗一下Jmeter日誌(文件位置：JMeter_Home_Directory/bin)的後一個線程開始時第一個線程是否真正結束了，二者的時間差是否正常。
總之，是否能確定一個適當的ramp-uptime取決於以下兩條規則:
·第一個取樣器的點擊率（hitrate）是否接近其他取樣器的平均值，從而能否避免ramp-upperiod過小。
·在後一個線程啟動時，第一個線程是否在真正結束了，好二者的時間要儘可能的長，以避免ramp-upperiod過大。
有時，這兩條規則的結論會互相衝突。這意味著無法找到同時滿足兩條規則的合適的ramp-upperiod。糟糕的測試計劃通常會導致這些問題，這是因為在這樣的測試計劃裏，取樣器將不能充分地採集數據，可能因為測試計劃執行時間太短並且線程會很快的運行結束。
用戶思考時間（Userthinktime），定時器，和代理伺服器（PRoxyserver）
在負載測試中需要考慮的的一個重要要素是思考時間（thinktime），也是在兩次成功的訪問請求之間的暫停時間。有多種情形揮發導致延遲的發生：用戶需要時間閱讀文字內容，或者填表，或者查找正確的鏈接等。未認真考慮思考時間經常會導致測試結果的失真。例如，估計數值不恰當，也是被測系統可以支持的多用戶量（並發用戶）看起來似乎要少一些等。
當我們進入正在的負載測試後，如果發現事務控制器的時間比所有子組件的時間之和差距過大，那麼說明Jmeter本身的性能出問題了。可以考慮通過如下三種方式進行處理：
一、修改Jmeter.bat文件，調整JVM參數，將heap和permsize值適當的設置大一點。
二、聯機負載，減少單臺機器上的負載線程數。
三、採用命令模式運行測試。
Jmeter提供了一整套的計時器（timer）來模擬思考時間（thinktime），但是仍然存在一個問題：:如何確定適當的思考時間呢？幸運的是，JMeter提供了一個不錯的答案：使用JMeterHTTP代理伺服器（ProxyServer）元件。
代理伺服器會記錄在使用一個普通的瀏覽器（如Firefox或InternetEXPlorer）瀏覽一個web應用時的操作。另外，JMeter在記錄操作的同時會建立一個測試計劃（testplan）。這個功能能提供以下便利：
不必手工建立HTTP訪問請求，尤其是當要設置一些令人乏味的參數時（然而，非英文的參數也許不能正常工作)。JMeter將會錄製包括隱含欄位（hiddenfields）在內的所有內容。
在生成的測試計劃中，Jmeter會包含瀏覽器生成的所有的HTTP報頭，如User-Agent(e。g。，Mozilla/4。0)，或AcceptLanguage(e。g。，zh-tw，en-us;q=0。7，zh-cn;q=0。3)等。
JMeter會根據設置在錄製操作的同時建立一些定時器，其延遲時間是完全根據真實的操作來設置的
現在讓我們來看一下如何配置Jmeter的錄製功能。在JMeter的控制檯上，在工作臺（WorkBench）元件上單擊右鍵，然後選擇」addtheHTTPProxyServer「。注重是在WorkBench上單擊右鍵而不是在TestPlan上，因為現在是要為記錄操作進行配置而不是要運行測試計劃。HTTPProxyServer的實現原理是通過配置瀏覽器的代理伺服器而使所有的訪問請求通過JMeter發送（，因而被Jmeter把訪問過程錄製下來）。
HTTP代理伺服器（HTTPProxyServer）元件的一些參數必須被配置:
埠(port):代理伺服器的監聽埠
目標控制器（TargetController）:是代理用於存儲生成的數據的控制器，默認情況下，JMeter將會在當前的測試計劃中找一個記錄用的控制器用於存儲，此外也可以在下拉菜單中選擇任意控制起來存儲，通常默認值可以了。
分組(Grouping):確定在測試計劃中如何來為生成的元件分組。有多個選項，一般可以選擇「只存儲每個組的第一個樣本」，否則，將會原樣錄製URLs，包括包含圖像和javascripts腳本的頁面。當然也可以嘗試一下默認值「不對樣本分組」（"Donotgroupsamples"），來看一下JMeter建立的原版的測試計劃。
包含模式(PatternstoInclude)和排除模式(PatternstoExclude):幫助過濾一些不需要的訪問請求。
推薦閱讀：
