性能測試day05_Jmeter學習


  今天來學習下jmeter這個性能測試工具,雖然說性能測試最主要的是整個性能的思路,但是也少不了工具的幫忙,從以前主流的LR到jmeter的興起,不過對於性能測試來說,個人感覺jmeter比較適合接口性能測試(因為工具比較輕盈,而且主要是模擬用戶負載,當然我也不否認可以做多業務的性能),既然說到這里,那么來簡單說下jmeter的優缺點,當然這個也主要是跟LR進行的對比,這里簡單說幾個:

   jmeter優點:

  • 開源,不收錢
  • 工具小但能干的活卻基本上接近LR
  • 擴展性強,而且懂java的人比C多

  缺點:

  • 缺少一個成型的體系,初學者學性能沒有整體概念,且界面也沒那么爽,剛學的人是懵逼的,跑起性能來啥情況都不知道
  • 最大的吐槽點應該就是對於線程的管理,LR是有專門的進程對多線程進行管理,而jmeter則是無腦開(無腦開線程會導致cs指標升高,cs代表進程與線程的交互次數,上篇講過),把自己搞死了都不知道。。。
  • 錄制也沒LR那么爽,LR能對很多資源自己丟一個請求里面,jmeter不行,錄制都是一堆鬼玩意,所以說這個東西做接口壓測比較好

行了,不多說了,我們來接着學習jmeter的使用吧,在學習用之前,我們先看下jmeter有哪些目錄以及是干啥用的。這里玩的是新版本jmeter4.0。

jmeter4.0的目錄如下:

  • backups(這個之前版本是沒有的,4.0新增的,備份腳本的目錄,當然還是自己記得保存最好,萬一它沒保存那就尷尬了)
  • bin(可執行文件目錄)
    1. examples(目錄中有CSV樣例)

    2. jmeter.bat(windows的啟動文件)

    3. jmeter.log(jmeter運行日志文件)

    4. jmeter.sh(linux的啟動文件)

    5. jmeter.properties(系統配置文件)

    6. jmeter-server.bat(windows分布式測試要用到的服務器配置)

    7. jmeters-server( linux分布式測試要用的服務器配置)

  • docs(文檔目錄,api文檔)
  • extras(擴展插件目錄,ant依賴,里面還有監控的GrafanaJMeterTemplate.json,就是上次監控提到的jmeter監控模板)
  • lib所用到的插件目錄,里面全是jar包,JMeter 會自動在 JMETER_HOME/lib(這個目錄下是依賴的外部jar包) 和 ext 目錄(核心jar包)下尋找需要的類
  • Printable_docs(用戶使用手冊,幫助文檔,英文好的看這個目錄的文檔就可以進行修煉了)
  • Licenses(jmeter證書目錄)

現在就讓我們來學習下jmeter的正式使用吧,用jmeter進行錄制有兩種方式,一個是badboy一個是jmeter代理錄制,當然除了錄制你還可以手寫,這個也是比較常用的。下面就來簡單說下代理錄制:

由於需要jmeter測試,所以我在cantos7.2上已經安裝了lamp和phpwind8.5,有人說這個環境安裝有點麻煩,我這里稍微提一下吧,安裝總共分為兩步,第一個是先裝lamp,我是安裝這篇博客來的,https://blog.csdn.net/u012980068/article/details/70228424裝完之后就去下載phpwind8.5 utf-8的版本,然后把upload改成phpwind丟到/var/www/html下,注意一下在做這些操作前要關閉防火牆和selinux,丟完之后最好將phpwind整個都賦予777的權限,然后去到界面通過http://ip/phpwind訪問安裝即可。

打開jmeter之后,新建線程組和HTTP代理服務器,然后選擇目標控制器為“Test Plan > 線程組”,由於jmeter錄制請求的時候會很多js、css等資源,因此我們可以通過包含模式和排除模式過濾一些不必要的請求,一般在做項目性能的時候,建議先錄制,我們可以參考着錄制然后抓包寫請求,除非你牛逼,對業務前后台非常熟,否則還是錄制參考下,以免遺漏請求。

這里我們來看下jmeter常用的一些組件,這些組件等下我登錄發帖整個流程會用到:

  1. 邏輯控制器
    • 事務控制器(一般把幾個操作放在一個事務,便於管理)
    • 僅一次控制器(一般用於登錄)
  2. Sample
    • http請求(主要是用於http請求)
    • java請求(主要用於自己條使用)
    • Debug sample(也是debug調試用的)
  3. 前置處理器->這里面好像就一個用戶參數用得比較多
  4. 后置處理器->這里面是正則表達式用的比較多,主要用於關聯
  5. 斷言->我一般都用響應斷言,這里主要是做檢查點的
  6. 定時器->固定定時器比較多,用於模擬用戶思考時間等,也可以不用,看業務需求
  7. 配置元件
    • CSV 數據文件設置(主要用戶參數化)
    • HTTP Cookie 管理器(用於cookie管理,一般我們都需要)
    • HTTP信息頭管理器(有些請求需要特殊的請求頭,此時可以進行添加,一般我們錄制后的每個請求都會帶一個信息頭管理器)
    • HTTP請求默認值(一般放在最前面,這樣所有請求都只需要填寫路徑即可,而且ip變化之后只需要改這里就行了)
  8. 監聽器
    • 查看結果樹(查看每次請求的具體內容)
    • 聚合報告(所有請求的統計過程)

下面我以登錄發帖為例,給大家講解下jmeter部分常用組件的用法,我們首先來指定一個場景,場景如下:

總共10個用戶請求,每5秒2個用戶登陸然后開始發帖,每個用戶登陸一次然后每隔一秒發一次帖子,十個人持續發帖60秒,然后按照5秒兩個用戶停止發帖。(場景可以自己隨便定義,舉個例子而已),場景設置如下圖,是不是和LR很像呢?這個需要先下載jmeter插件才會有的,可以百度搜索“Jmeter plugin”然后下載解壓將jar包放在lib->ext下。

  接下來大致講解下用到的元件,從上往下依次說下,這里不會詳細說明每個組件的意思,不懂得可以百度,有太多說明了。我主要是講解一下思路,

  1. 首先我們看到在最前面有個cookie管理器,這個是需要的,因為沒有這個的話那我們登錄之后發帖的事就干不成了,這里注意一點就是有個“每次反復清理cookie”的選項,如果選了就會每次清理cookie,這里我們是僅登錄一次所以不勾選;
  2. HTTP請求默認值,我們對論壇進行測試,那么就可以將每個請求默認訪問服務器的地址先寫在這個請求默認值里面,第一是以后請求可以少些點東西,第二如果ip發送了變化,那么我們只需要修改這里就行了。
  3. 僅一次控制器,我這里將登陸的請求都放到了僅一次控制器下面,這里要注意下,那個csv的參數文件也必須放在這里,如果放在外面的話那么發帖也會自己讀參數,所以發帖的參數跟着登陸的就行了。
  4. CSV 數據文件設置,這里我們參數化了用戶名和密碼(之前已經通過參數化注冊了兩百個用戶,需要注意下,如果是注冊的話倒數二三的選項要與下圖相反)
  5. 響應斷言,這里主要登陸登陸和發帖做了兩處斷言,你可以先成功登錄和發帖一次看下成功和失敗不同的響應是啥,然后斷言即可。
  6. 正則表達式提取器,這里我們在發帖的參數發現有個參數verify是一直變的,因此我們將其關聯,關聯的參數要在發帖前的頁面去尋找,找到后用正則提取出來即可,可能找到的會不只一個,所以我們選擇了第一個。
  7. 事務控制器,這里我將點擊跳轉至發帖頁面和提交發帖還有跳轉讀貼為一個事務,因為這跟我們用戶操作是一樣的,我們發帖都是等跳轉至發完貼的頁面用戶才能感知到發帖成功,因此算作一個事務,可以看下事務控制器有兩個勾選項,可以看下意思,默認是沒勾選的。
  • Generate parent sample:(選中這個參數結果就只會展示整個事務,不會顯示每個請求,不勾選則顯示每個請求和事務)
  • Include duration of timer and pre-post processors in generated sample:選中這一項會統計定時器(timer)的時間,否則只統計采樣器(sample)的時間

8.固定定時器,這里只是模擬一下用戶發帖前需要填寫帖子內容再發,這里設置為了1秒,實際上應該不止一秒的,這里只是做個測試而已。不過這個固定定時器的時間雖然不會計算在請求內,但是會計入到事務內,因此我們在看響應時間的時候可以減去這個時間,也可以取消事務的勾選,看下單個請求的時間。

9.最后添加一個查看結果樹和聚合報告看下情況,還有Backend Listener,這樣我們的數據就會寫入到influxdb里面,我們可以結合之前我們寫的jmeter模板還要linux監控一起看下測試情況和資源使用情況。

我們跑起來看一下整天情況,在跑之前我先看下帖子的數量:3810個帖子

我們開跑,可以從這里看到一分多鍾的時間,總共發出去了736個請求,所有請求都成功了,所以帖子數也變成了4546個;

下圖可以看到TPS為9.2(持續60時候的峰值TPS),對應響應時間為50ms,整個事務的時間是100+ms,看完這個后,我們來接着看下監控。

 監控如下,可以看到在17:40:30的時候,TPS是最高的,cpu使用率為也是占用最多,可以看到隊列數為3,上下文交互是2K,可以看到在該壓力下,系統的各個指標還未達到任何瓶頸,這里主要是給大家串一下整個思路,之后會根據實戰具體分析下性能,感興趣的也可以並發多用戶或者把固定時間去掉提高TPS,看下性能如何?

在這里我又重新執行了下面的場景,而且去掉了固定時間,所以整個的壓力是非常大的,我們來看下結果:

jmeter各個請求及事務的情況如下,可以看到最大的發帖時間已經有1+秒了,TPS最大為25左右也上不去了,接着我們再看下服務器資源監控:

論壇服務器的服務器配置是2C2G的,所以看到隊列有50+個,我們可以知道,cpu肯定是扛不住這么大的壓力了。嘻嘻,簡單分析到這里吧!以后再來更詳細的分析咯。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM