利用Jmeter完成簡單的介面效能測試

NO IMAGE

一.效能測試指標

在用jmeter做效能測試之前,首先要回顧下效能測試的關鍵指標

1.系統吞吐量 throughput

單位時間內系統的請求數目

在沒有達到效能瓶頸時吞吐量和虛擬使用者間存在一定的聯絡

 F=VU * R /T ——VU:虛擬使用者數,R:每個使用者發出的請求數,T:考察的時間

2.響應時間(系統延遲)

通常一個系統的效能受吞吐量和響應時間兩個條件的約束,有以下兩種場景

吞吐量越大,系統延遲越大,因為請求量過大,系統繁忙,響應速度降低

系統延遲越好,能支援的吞吐量就越高,因為響應速度快,因此能處理更多的請求

3.併發數

系統能夠同時處理的請求數/事務數

4.QPS(TPS)

併發數/響應時間 假定系統響應時間一致的情況下,併發數越大,QPS也越高;當併發數超過一定值(系統瓶頸)時,響應時間變慢,QPS降低

依賴於公司的監控系統,做介面壓力測試時主要關注點在qps,響應時間以及準確率,併發數是要靠算的

二.jmeter介面測試

建立測試計劃,新增執行緒組,線上程組裡面新增HTTP請求,設定http請求詳情(包括伺服器IP和埠號,協議,方法,編碼,請求方法,方法中的引數等),為http請求新增請求頭,為了檢視jmeter的執行結果,需要新增監聽器(常用的有“檢視結果樹”和“聚合報告”)

這裡不再重複贅述:可參考其餘教程

如何使用csv檔案實現引數化:新增配置元件CSV Data Set Config 

以下介紹一些配置項的概念

1.執行緒組管理:設定執行緒數,設定ramp_up period,設定執行測試的次數

執行緒組元件控制Jmeter執行測試時使用的執行緒數,每個執行緒會作為一個整體執行測試計劃並完全獨立於其他測試執行緒,多執行緒用來模擬到達伺服器的同步連線;Ramp-up period告訴JMeter多久開始”ramp-up”選擇的全部執行緒。如果使用10個執行緒,ramp-up period是100秒,那麼JMeter用100秒使所有10個執行緒啟動並執行。每個執行緒會在上一個執行緒啟動後10秒(100/10)啟動。如果有30 個執行緒和一個120秒的ramp-up period,那麼每個連續的執行緒會延遲4秒; 

修改jmeter的執行緒數會加快資料的生成速度。

你的硬體能力會限制你有效執行JMeter的執行緒數。它也會依賴於你伺服器的速度(一個更快的伺服器因為它更加快速的返回一個請求所以會使 JMeter工作更加努力)。JMeter工作越多,它的時間資訊就越不準確。JMeter做越多的動作,每個執行緒必須等待訪問CPU的時間越長,定時信 息越長。如果你需要大規模的負載測試,考慮在多個機器上執行多個非使用者介面的JMeter。

這裡需要明確併發的概念,曾經看到小夥伴在單機筆記本上發起了600個執行緒,這種情況下設定執行緒數過多資源不足負載機排隊,另外請求資料在網路佇列上也有排隊,到達服務端也會排隊,嚴格意義上的併發很難指定,如果不能達到效能測試的瓶頸,可以考慮增加機器

減少資源使用的一些建議:   使用非使用者介面模式:jmeter -n -t test.jmx -l test.jtl  儘可能少的使用監聽器;如果使用-l標誌     不要使用函式模式   使用CSV輸出而不是XML  僅儲存你需要的資料   儘可能少的使用斷言

三.壓力模擬工具

 若為Java類介面且單機併發數控制在500內,則可選擇Jmeter或者 Loadrunner。
 若為WebService類介面且單機併發數控制在500內,則可選擇SoapUI或者Loadrunner。
 若單機併發數超過500且控制在5000內,則可選擇Loadrunner。
 若單機併發數超過5000,則建議採用負載叢集,即採用“中控(Control Center) 多機部署(Load Generator)”方案。
以上僅代表個人理解

四.測試場景

1. 系統達到 **qps時的響應時間;
2.單個機器可以達到的qps ;總的請求數不變,逐漸增加執行緒數(執行緒數越大,資料的生成速度越快,總的請求數不變,當qps不隨執行緒數的增大而改變時,可以認為得到了結果值)
參考:http://blog.jobbole.com/106140/