JMeter 是一個流行的用于負載測試的開源工具， 具有許多有用的功能元件，如線程組（thread group）， 定時器（timer）， 和HTTP 取樣 (sampler) 元件。 本文是對JMeter 用戶手冊的補充，而且提供了關于使用Jmeter的一些模擬元件開發質量測試腳本的指導。

　　本文同時也討論了一項重要的內容：在指定了精確的響應時間要求后，如何來校驗測試結果，特別是在采用了置信區間分析這種嚴格的統計方式的情況下應如何操作。請注意，我假定本文的讀者們了解關于Jmeter的基礎知識，本文的例子基于Jmeter2。0。3版。 

　　確定一個線程組的ramp-up period （Determine）

　　Jmeter腳本的第一個要素是線程組（Thread Group），因此首先讓我們來回顧一下。 正如圖一所示，線程組需要設置以下參數： 
　　·線程數量。 
　　·ramp-up period。 
　　·運行測試的次數。 
　　·啟動時間:立即或者預定的時間，如果是后者，線程組所包含的元素也要指定這個起止時間。

　　圖 1。 JMeter 線程組（JMeter Thread Group）

　　每個線程均獨立運行測試計劃。因此， 線程組常用來模擬并發用戶訪問。如果客戶機沒有足夠的能力來模擬較重的負載，可以使用Jmeter的分布式測試功能來通過一個Jmeter控制臺來遠程控制多個Jmeter引擎完成測試。 

　　參數 ramp-up period 用于告知JMeter 要在多長時間內建立全部的線程。默認值是0。如果未指定ramp-up period ，也就是說ramp-up period 為零， JMeter 將立即建立所有線程，假設ramp-up period 設置成T 秒， 全部線程數設置成N個， JMeter 將每隔T/N秒建立一個線程。 

　　線程組的大部分參數是不言自明的，只有ramp-up period有些難以理解， 因為如何設置適當的值并不容易。 首先，如果要使用大量線程的話，ramp-up period 一般不要設置成零。 因為如果設置成零，Jmeter將會在測試的開始就建立全部線程并立即發送訪問請求， 這樣一來就很容易使服務器飽和，更重要的是會隱性地增加了負載，這就意味著服務器將可能過載，不是因為平均訪問率高而是因為所有線程的第一次并發訪問而引起的不正常的初始訪問峰值，可以通過Jmeter的聚合報告監聽器看到這種現象。 
這種異常不是我們需要的，因此，確定一個合理的ramp-up period 的規則就是讓初始點擊率接近平均點擊率。當然，也許需要運行一些測試來確定合理訪問量。 

　　基于同樣的原因，過大的ramp-up period 也是不恰當的，因為將會降低訪問峰值的負載，換句話說，在一些線程還未啟動時，初期啟動的部分線程可能已經結束了。 

　　那么，如何檢驗ramp-up period I太小了或者太大了呢？首先，推測一下平均點擊率并用總線程除點擊率來計算初始的ramp-up period。 例如，假設線程數為100， 估計的點擊率為每秒10次， 那么估計的理想ramp-up period 就是 100/10 = 10 秒。 那么，應怎樣來提出一個合理的估算點擊率呢？沒有什么好辦法，必須通過運行一次測試腳本來獲得。

　　其次， 在測試計劃（test plan）中增加一個聚合報告監聽器，如圖2所示，其中包含了所有獨立的訪問請求（一個samplers）的平均點擊率。 第一次取樣的點擊率（如http請求）與ramp-up period 和線程數量密切相關。通過調整ramp-up period 可以使首次取樣的奠基率接近平均取樣的點擊率。 

　　圖2 JMeter 聚合報告 

　　第三， 查驗一下Jmeter日志(文件位置：JMeter_Home_Directory/bin) 的最后一個線程開始時第一個線程是否真正結束了，二者的時間差是否正常。

　　總之，是否能確定一個適當的ramp-up time 取決于以下兩條規則: 
　　·第一個取樣器的點擊率（hit rate）是否接近其他取樣器的平均值，從而能否避免ramp-up period 過小。
　　·在最后一個線程啟動時，第一個線程是否在真正結束了，最好二者的時間要盡可能的長，以避免ramp-up period過大。

　　有時，這兩條規則的結論會互相沖突。 這就意味著無法找到同時滿足兩條規則的合適的ramp-up period。 糟糕的測試計劃通常會導致這些問題，這是因為在這樣的測試計劃里，取樣器將不能充分地采集數據，可能因為測試計劃執行時間太短并且線程會很快的運行結束。 

原文轉自：http://www.anti-gravitydesign.com