JMeter壓測例子
【後臺測試】手把手教你jmeter壓測
◆版權宣告:本文出自胖喵~的部落格,轉載必須註明出處。
轉載請註明出處:http://www.cnblogs.com/by-dream/p/5611555.html
我知道我遲早是要踏上了後臺測試之路的,只是沒想到來的這麼突然。新接手了一個專案,在第一版發出後,產品需要做運營活動拉量,因為我擔心突然的流量湧入是否會對後臺造成壓力呢?因此決定做一下壓測:
下面就一步一步的介紹我從0到1的壓測過程吧。
我下載的是 apache-jmeter-2.13,因為這個包下載下來通用linux和windows的,所以我們現在windows下開啟它。
直接點選bat,開啟jmeter:
新增一個執行緒組:
新增完成之後,先設定這兩項:
然後右擊左邊的執行緒組,新增一個http請求
新增完成之後,我們可以看到右邊有了可以編輯的地方:
這裡打算壓測這樣一個url,這個url請求是 http://cm.browser.qq.com/test_xianwu/api/buy
也就是拉取App的首頁的資訊
我們直接用瀏覽器開啟是這樣的:
見下圖,我們需要把url分成兩部分填寫
這個時候點選儲存,儲存的檔案路徑自己指定,我儲存到了bin目錄下,儲存完之後,是一個jmx檔案。
儲存完畢之後呢,我們需要,在壓測的過程中,去檢視請求的結果,因此需要新增一個“檢視結果樹”
新增完畢之後的樣子:
這個時候我們點選啟動,看看效果吧:
這個時候我們把執行緒數加大,先加達到100
加完之後,我去App端看了一眼,然後發現首頁悲劇了,一片白屏:
這時候我們在網站上去看一下,發現果然,返回的子串當中,list的內容為空了,而這個list就是我們首頁要展示出的物品:
既然我們知道了請求返回失敗的特徵是list為空,那麼就增加一個斷言,讓他直接幫我們篩選出請求失敗的樣本。
同樣右擊,“新增”-“斷言”-“響應斷言”,新增完成之後,我們新增一個substring:
這裡說一下location是什麼鬼。因為在請求成功的情況下,返回的list當中的資訊當中有location,所以我們可以簡單的認為,當location欄位存在的時候,這個請求是成功的。
這個時候我們再執行一下,看看結果樹當中會不會幫我們辨別出來:
我們可以看到紅色就是失敗的個數。數量有點多,所以我們需要藉助Aggregate Graph
新增完成之後,我們啟動我們的服務,這個時候就能在這裡看到一個大概的資料了:
這樣我們就可以不斷的去改變執行緒數,然後去觀察失敗率和吞吐量,得到一個當前請求的一個最佳的相應數。
在測試的過程中我發現,如果手動去強制停止的話,最後的幾條請求會因為手動停止而丟擲異常,因此我們決定讓他去請求2w次,2w次結束收自動停止。那麼我們就需求在開始的地方設定採集次數:
這裡需要注意執行緒數和迴圈次數的乘積等於一個固定值就可以,然後你可以變換兩個乘數,最終我選擇了執行緒數分別是10、20、50、80、100、200,得到的結果是:
最後生成圖表,就可以看出來效能的瓶頸,下面是結果:
從圖中我們不難看出響應時間延時很大,且錯誤率非常高,並且最大qps才能打到50出頭,所以初步懷疑這是有效能問題的,最終反饋給開發,開發加入了快取機制,並且增加了機器,經過優化之後,我們再看看資料對比:
很明顯優化後的效果顯著,達到了預期的效果。
這就是我第一次簡單壓力測試的經過,看完後是不是你也可以做了。