Jmeter 使用總結_jmeter

JMeter用於類比在伺服器、網路或者其他對象上附加高負載以測試他們提供服務的受壓能力，或者分析他們提供的服務在不同負載條件下的總效能情況。 Graph Results

Jmeter 測試結果中包括：樣本數目、最新樣本、平均、偏離、輸送量、中值，需要記住這些指標的含義。
- 樣本數目：是指在測試過程中，總共向伺服器發出的請求數目。成功的情況下等於你設定的 並發數目迴圈次數請求個數
- 最新樣本：表示伺服器響應最近一個請求的時間。
- 輸送量 ：表示伺服器每分鐘處理的請求數目。
- 平均值 ：總的已耗用時間除以發送到伺服器的請求數目；
- 偏離 ：伺服器回應時間變化、離散程度測量值的大小，或者，換句話說，就是資料的分布。
- 中值 : 時間的數字，有一半的伺服器回應時間低於該值而另一半高於該值。 Aggregate Report 的KPI

Label：每個 JMeter 的 element（例如 HTTP Request）都有一個 Name 屬性，這裡顯示的就是 Name 屬性的值
‘#Samples‘：表示你這次測試中一共發出了多少個請求，如果類比10個使用者，每個使用者迭代10次，那麼這裡顯示100
Average：平均回應時間——預設情況下是單個 Request 的平均回應時間，當使用了 Transaction Controller 時，也可以以Transaction 為單位顯示平均回應時間
Median：中位元，也就是 50％ 使用者的回應時間
90% Line：90％ 使用者的回應時間
Min：最小回應時間
Max：最大回應時間
Error%：本次測試中出現錯誤的請求的數量/請求的總數
Throughput：輸送量——預設情況下表示每秒完成的請求數（Request per Second），當使用了 Transaction Controller 時，也可以表示類似 LoadRunner 的 Transaction per Second 數
KB/Sec：每秒從伺服器端接收到的資料量，相當於LoadRunner中的Throughput/Sec

手工製作測試指令碼，需要你知道請求的url和攜帶的參數等等，太花費時間，所以可以用badboy工具錄製指令碼。這個工具雖然不是開源的，但是卻可以用來免費的錄製成.jmx的指令碼，使用起來很方便。
官方網站是：http://www.badboy.com.au/

附件：
對於並發量的處理：
50QPS以下——小網站
簡單的小網站，可以用最簡單的方法快速搭建，短期沒有太多的技術瓶頸，只要伺服器不要太爛基本上都可以滿足。
50～100QPS——DB極限型
大部分的關係型資料庫的每次請求大多都能控制在0.01秒左右，即便你的網站每頁面只有一次DB請求，那麼頁面請求無法保證在1秒鐘內完成100個請求，這個階段要考慮做Cache或者多DB負載。無論那種方案，網站重構是不可避免的。

300～800QPS——頻寬極限型
目前伺服器大多用了IDC提供的“百兆頻寬”，這意味著網站出口的實際頻寬是8M Byte左右。假定每個頁面只有10K Byte，在這個並發條件下，百兆頻寬已經吃完。首要考慮是CDN加速／異地緩衝，多機負載等技術。

500～1000QPS——內網頻寬極限＋Memcache極限型
由於Key/value的特性，每個頁面對memcache的請求遠大於直接對DB的請求，Memcache的封閉式並行存取數在2w左右，看似很高，但事實上大多數情況下，首先是有可能在次之前內網的頻寬就已經吃光，接著是在8K QPS左右的情況下，Memcache已經表現出了不穩定，如果代碼上沒有足夠的最佳化，可能直接將壓力轉嫁到了DB層上，這就最終導致整個系統在達到某個閥值之上，效能迅速下滑。

1000～2000QPS——FORK/SELECT，鎖模式極限型
好吧，一句話：執行緒模式決定輸送量。不管你系統中最常見的鎖是什麼鎖，這個層級下，檔案系統訪問鎖都成為了災難。這就要求系統中不能存在中央節點，所有的資料都必須分布儲存，資料需要分布處理。總之，關鍵詞：分布