【後臺測試】手把手教你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次結束收自動中止。那麼咱們就需求在開始的地方設置採集次數：

　　這裏須要注意線程數和循環次數的乘積等於一個固定值就能夠，而後你能夠變換兩個乘數，最終我選擇了線程數分別是十、20、50、80、100、200，獲得的結果是：

　　最後生成圖表，就能夠看出來性能的瓶頸，下面是結果：

　　

 　　從圖中咱們不難看出響應時間延時很大，且錯誤率很是高，而且最大qps才能打到50出頭，因此初步懷疑這是有性能問題的，最終反饋給開發，開發加入了緩存機制，而且增長了機器，通過優化以後，咱們再看看數據對比：

　　很明顯優化後的效果顯著，達到了預期的效果。

　　這就是我第一次簡單壓力測試的通過，看完後是否是你也能夠作了。