我知道我遲早是要踏上了後臺測試之路的，只是沒想到來的這麽突然。新接手了一個項目，在第一版發出後，產品需要做運營活動拉量，因為我擔心突然的流量湧入是否會對後臺造成壓力呢？因此決定做一下壓測：

　　下面就一步一步的介紹我從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出頭，所以初步懷疑這是有性能問題的，最終反饋給開發，開發加入了緩存機制，並且增加了機器，經過優化之後，我們再看看數據對比：

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

　　這就是我第一次簡單壓力測試的經過，看完後是不是你也可以做了。

【後臺測試】手把手教你jmeter壓測