jmeter學習筆記（小tips）

聚合報告說明：

一、throughput：吞吐量，默認狀況下表示每秒完成的請求數( Request per Second )

二、KB/Sec:每秒從服務器端接收到的數據量

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。 糟糕的測試計劃一般會致使這些問題，這是由於在這樣的測試計劃裏，取樣器將不能充分地採集數據，可能由於測試計劃執行時間過短而且線程會很快的運行結束。 



　　用戶思考時間（User think time），定時器，和代理服務器（proxy server）

　　在負載測試中須要考慮的的一個重要要素是思考時間（think time）， 也就是在兩次成功的訪問請求之間的暫停時間。 有多種情形揮發致使延遲的發生： 用戶須要時間閱讀文字內容，或者填表， 或者查找正確的連接等。未認真考慮思考時間常常會致使測試結果的失真。例如，估計數值不恰當，也就是被測系統能夠支持的最多用戶量（併發用戶）看起來好像要少一些等。 

　　Jmeter提供了一整套的計時器（timer）來模擬思考時間（think time）， 可是仍舊存在一個問題：: 如何肯定適當的思考時間呢？幸運的是， JMeter 提供了一個不錯的答案：使用 JMeter HTTP 代理服務器（Proxy Server）元件。 

　　代理服務器會記錄在使用一個普通的瀏覽器（如FireFox 或 Internet Explorer）瀏覽一個web應用時的操做。 另外， JMeter 在記錄操做的同時會創建一個測試計劃（test plan）。 這個功能能提供如下便利： 

　　·沒必要手工創建HTTP 訪問請求， 尤爲是當要設置一些使人乏味的參數時（然而，非英文的參數也許不能正常工做) 。JMeter 將會錄製包括隱含字段（hidden fields）在內的全部內容。 

　　·在生成的測試計劃中，Jmeter會包含瀏覽器生成的全部的 HTTP 報頭，如User-Agent (e。g。， Mozilla/4。0)， 或Aclearcase/" target="_blank" >cceptLanguage (e。g。， zh-tw，en-us;q=0。7，zh-cn;q=0。3)等。 

　　·JMeter 會根據設置在錄製操做的同時創建一些定時器，其延遲時間是徹底根據真實的操做來設置的
如今讓咱們來看一下如何配置Jmeter的錄製功能。 在JMeter 的控制檯上， 在工做臺（WorkBench）元件上單擊右鍵，而後選擇」add the HTTP Proxy Server 「。 注意是在WorkBench 上單擊右鍵而不是在Test Plan上， 由於如今是要爲記錄操做進行配置而不是要運行測試計劃。  HTTP Proxy Server 的實現原理就是經過配置瀏覽器的代理服務器而使全部的訪問請求經過JMeter發送（，於是被Jmeter把訪問過程錄製下來）。 

　　如圖3所示， HTTP代理服務器（HTTP Proxy Server）元件的一些參數必須被配置: 

　　·端口(port): 代理服務器的監聽端口 

　　·目標控制器（Target Controller）: 是代理用於存儲生成的數據的控制器，默認狀況下，， JMeter 將會在當前的測試計劃中找一個記錄用的控制器用於存儲，此外也能夠在下拉菜單中選擇任意控制起來存儲，一般默認值就能夠了。 

　　·分組(Grouping): 肯定在測試計劃中如何來爲生成的元件分組。 有多個選項， 通常能夠選擇「只存儲每一個組的第一個樣本」，不然，將會原樣錄製URLs，包括包含圖像和JavaScripts腳本的頁面。固然 也能夠嘗試一下默認值「不對樣本分組」（"Do not group samples"），來看一下JMeter 創建的原版的測試計劃。 

　　·包含模式(Patterns to Include) 和 排除模式(Patterns to Exclude) :幫助過濾一些不須要的訪問請求。

　　圖 3。 JMeter 代理服務器(Proxy Server)。

　　當你點擊開始（Start）按鈕時，代理服務器就會開始記錄所接受的HTTP 訪問請求。 固然，在開始記錄前，要首先設置好瀏覽器的代理服務器設置。在代理服務器元件中能夠增長一個定時器子元件（配置元件），用於告知Jmeter來在其生成的HTTP請求中自動的增長一個定時器。Jmeter會自動把實際的延遲時間存儲爲一個被命名爲T的Jmeter變量，所以，若是在代理服務器元件裏使用了高斯隨機定時器，就應該在其中的固定延遲偏移（Constant Delay Offset）設置項裏添上${T}（用於自動引用紀錄的延遲時間），如圖4所示。這是另外一個節省時間的便利特性。 

點擊查看大圖

 

　　圖 4。 在代理服務器組建中增長一個高斯隨機定時器 


　　定時器將會使相應的的取樣器被延遲。 延時的規則是，在上一個訪問請求被響應並延時了指定的時間後，下一個被定時器影響的取樣訪問請求才會被髮送出去。 所以， 你必須手工刪除第一個取樣器中自動生成的定時器，由於第一個取樣器不須要定時器。 

　　在啓動HTTP代理服務器之前，要在測試計劃中增長一個線程組（thread group），在線程組中增長一個錄製控制器（recording controller）用於存儲生成的結果。 不然， 生成的元件將會被直接添加到工做臺裏。另外， 在錄製控制器裏增長一個HTTP請求默認值元件HTTP Request Defaults 元件 (是一個配置元件) 也很重要，這樣Jmeter就不填寫使用了默認值的字段。 

　　錄製完成後， 中止HTTP 代理服務器; 在錄製控制器元件上單擊右鍵將記錄的元件保存爲一個文件用於之後重用，另外，不要忘了恢復瀏覽器的代理服務器設置。 

　　指定響應時間需求並校驗結果

    　儘管本節內容與Jmeter不是直接相關，可是Jmeter仍舊是指定響應時間需求和校驗測試結果這兩個負載測試評價任務互相聯繫的紐帶。

　　在web應用的環境裏，響應時間指的是從提交訪問請求到等到HTML結果所耗費的時間。從技術的角度看，響應時間也應包括瀏覽器重繪HTML頁面的時間，可是瀏覽器通常是一塊接着一塊地顯示而不是直接顯示完整的整個頁面，讓人感受響應時間要少一些。 另外，典型的狀況是，負載測試工具不會考慮瀏覽器的重繪時間。 所以， 在實際的性能測試中，咱們將考慮以上描述的情形， 若是不能確信，能夠在正常的響應時間上加一個固定值，如0.5秒。

　　如下是一套衆所周知的肯定相應時間的標準: 
　　·用戶將不會注意到少於0.1秒的延遲 
　　·少於1秒的延遲不會中斷用戶的正常思惟， 可是一些延遲會被用戶注意到 
　　·延遲時間少於10秒，用戶會繼續等待響應 
　　·延遲時間超過10秒後，用戶將會放棄並開始其餘操做

　　這些閥值頗有名而且通常不會改變，由於是關乎人類的感知特性的。 因此要根據這些規則來設置響應時間需求， 也須要適當調整以適應實際應用。例如，亞馬遜公司(Amazon.com) 的主頁也遵循了以上規則，可是因爲更偏重於風格上的一致，因此在響應時間上有一點損失。 

　　乍一看，好像有兩種不一樣的方式來肯定相應時間需求： 
　　·平均響應時間(Average response time )
　　·絕對響應時間（Absolute response time）;即， 全部的響應時間必須低於某一閥值

　　指定平均響應時間比較簡單一些（straightforward），可是因爲數據變化的干擾，這個需求每每難以實現。爲何取樣中的20%的響應時間要比平均值高3倍以上呢？請注意，JMeter 計算平均響應時間與圖形結果監視器中的標準誤差是一致的。 

　　另外一方面， 對絕對響應時間需求過於苛求是不實際的。 若是隻有0。5%的取樣不能經過測試該怎麼辦？若是再測一次，又會有很大的變化。 幸運的是， 使用置信區間（confidence interva）分析這種正規的統計方法能夠顧及到取樣變化的影響。 
在繼續進行前，讓咱們首先回顧一些基本的統計學知識。 

　　中心極限定理（The central limit theorem）
 
　　中心極限定理代表若是整體的分佈有一個平均值μ和標準誤差σ，那麼對於一個十分大的n(>30)，其取樣平均值的分佈將接近於正態分佈，其平均值μmean = μ ，標準誤差σmean = σ/√n。 
注意取樣平均值的分佈是正態的，而取樣自身的分佈沒必要是正態的。也就是說若是屢次運行測試腳本則測試結果的平均響應時間將會是正態的。 

　　圖 5 和圖 6 分別展現了兩個正態分佈。 在這裏橫座標是採樣響應時間的均值， 整體的均值被調整到座標的原點（shifted so the population mean is at the origin）。 圖5 代表90%的時間裏，採樣均值位於±Zσ的區間裏（percent of the time， the sampling means are within the interval ±Zσ，），這裏的Z=1.645 和 σ 是標準誤差。 圖 6 代表了99%的狀況下的情形這時的Z=2.576。 在給定的機率下，如90%， 咱們能夠看到相應的Z呈現正態曲線，反之亦然。 

　　Figure 5。 Z value for 90 percent
  

　　Figure 6。 Z value for 99 percent

　　在相關資料中所列的是可提供正態曲線計算的一些網站。在這些網站，咱們能夠計算隨意的相對區間內的機率(如，-1.5 < X < 1.5)或者在一個彙集的區域（cumulated area）內 ，(如， X < 1.5)。 也能夠從下面的表中獲得近似值。 

　　表 1。 對應於給定的置信區間（confidence interval）的標準誤差範圍（Standard deviation range）

　　表 2。 對應於給定的標準誤差範圍（Standard deviation）的置信區間（confidence interval）

　　置信區間（Confidence interval）
 
　　置信區間（confidence interval）的定義是[取樣平均值- Z*σ/√n， 取樣平均值+ Z*σ/√n]。 例如， 若是置信區間（機率）是90%， 經查找可知Z 值是1。645， 因而置信區間就是 [取樣平均值- 1。645*σ/√n， 取樣平均值+ 1。645*σ/√n]， 這意味着在90%的時間裏， 整體平均值（population mean）(是未知的) 會落入這個置信區間內。 也就是說， 咱們的測試結果是十分接近的。 若是 σ（標準誤差） 更大一些， 置信區間也會更大，這就意味着置信區間的上限就會更可能會越過能夠接受的範圍，即σ 越大，結果越不可信。 

　　響應時間需求（Response-time requirements ）
    
　　如今咱們把全部的信息都歸結到響應時間需求上來。首先。必需要定義性能需求，如: %95機率的置信區間的平均響應時間的上限必須小於5秒。 固然，最好有相應的需求或場景。 

　　在性能測試結束後，假設進分析得出結論是平均響應時間是4.5秒，標準誤差時4.9秒，樣本數量是120個，而後就能夠計算%95機率的置信區間了。 經過查表1，找到Z值是 1。95996。 因而置信區間就是 [4.5 – 1.95996*4.9/√120， 4.5 + 1.95996*4.9/√120]， 也就是 [3.62， 5.38]。 儘管看起來這個響應時間看起來很不錯，但這個結果（由於超出了需求的要求，於是）是不可接受的。 實際上， 能夠檢驗的是即便是對於80%機率的可信區間，這個測試結果也是不能接受的。正如你所看到的，使用了置信區間分析後，會獲得一個十分精確的方法來估算測試質量。 

　　在web應用中，爲了測定某一場景的響應時間，咱們通常要經過測試工具來發送多個訪問請求，例如： 
　　4. 登錄 
　　5. 顯示錶單 
　　6. 提交表單

　　假設咱們對請求3更感興趣。爲進行置信區間分析，咱們須要的僅是請求3的全部樣本的響應時間均值和標準誤差，而不是所有被統計的樣本的。 

　　在Jmeter的圖表結果監聽器中計算的倒是所有請求的響應時間均值和標準誤差。 而Jmeter的聚合報告監聽器計算的是獨立的採樣器的響應時間均值，惋惜沒有計算標準誤差。 
總之， 僅僅指定響應時間均值是危險的， 由於不能反映出數據的變化。 即便響應時間均值是能夠接受的，可是置信區間僅有75％，這個結果也不能使人信服。可是，使用置信區間分析仍是會帶來更多的肯定性。 

　　結論

　　本文討論瞭如下內容: 
　　·詳細講解了Jmeter 線程組在加載負載時的特別設置 

　　·使用Jmeter代理服務器(Proxy Server)元件自動創建測試腳本的指導方針，其重點在於模擬用戶思考時間（user think time ）。

　　·置信區間分析（Confidence interval analysis）， 一種咱們能夠用來更好地知足響應時間需求的統計分析方法

　　經過使用本文說起的技術能夠改善測試腳本的質量，更普遍地說，本文所討論的內容屬因而性能測試的一個工做流程的一部分， 是其中的一個較困難的部分。性能測試包括並不只限於如下內容： 

　　·編寫性能測試需求
　　·選擇測試情景 
　　·準備測試環境
　　·編寫測試腳本 
　　·執行測試
　　·回顧測試腳本和測試結果 
　　·指出性能瓶頸 
　　·書寫測試報告

　　此外， 性能測試結果，包括肯定下來的瓶頸， 都須要反饋給開發團隊或者架構師進行優化設計。 在這個過程當中，並寫測試腳本和回顧測試腳本是其中很重要的部分，要精心籌劃和管理實施。憑藉測試腳本指導和一個好的性能測試流程，你將會有更多的機會來在較重負載下優化軟件性能。


　　關於做者

　　Chi-Chang Kung 是臺灣Sun 公司的java系統架構師，也是IEEE 和ACM的成員。 

　　相關資源 

　　·JMeter: http://jakarta.apache.org/jmeter/index.html 
　　·《中心極限理論以及經典推論》（"Central Limit Theorem and Classical Inference" ）Scott M。 Lynch (2005年2月):http://www.princeton.edu/~slynch/clt_inference.pdf 

　　·置信區間（Confidence intervals）: http://people.hofstra.edu/faculty/Stefan_Waner/RealWorld/finitetopic1/confint.html 

　　·《java網站的性能分析》（Performance Analysis for Java Websites）， Stacy Joines et al. (Addison-Wesley， 2002年9月; ISBN: 0201844540): http://www.amazon.com/exec/obidos/ASIN/0201844540/javaworld ·《響應時間：三個重要的限制條件》("Response Times: The Three Important Limits") 引自《實用工程學》( Usability Engineering)， Jakob Nielsen (Morgan Kaufmann， 1994; ISBN 0125184069): http://www.useit.com/papers/responsetime.html 　　·一些提供了正態曲線計算功能的網站(Websites for normal curve calculation): 　　o        http://www.psychstat.smsu.edu/introbook/normal.htm 　　o        http://www.ecositebr.bio.br/curva_normal.htm 　　o        http://statistik.wu-wien.ac.at/mathstat/hatz/vo/applets/probCalc/normal_z_p.html　　·更多關於測試的文章，請參照JavaWorld's 標題索引的Testing 部分: http://www.javaworld.com/channel_content/jw-testing-index.shtml 　　·關於JAVA開發工具，參見JavaWorld's 標題索引的Development Tools 部分: http://www.javaworld.com/channel_content/jw-tools-index.shtml