【後臺測試】手把手教你jmeter壓測 html
我知道我早晚是要踏上了後臺測試之路的,只是沒想到來的這麼忽然。新接手了一個項目,在初版發出後,產品須要作運營活動拉量,由於我擔憂忽然的流量涌入是否會對後臺形成壓力呢?所以決定作一下壓測:linux
下面就一步一步的介紹我從0到1的壓測過程吧。apache
我下載的是 apache-jmeter-2.13,由於這個包下載下來通用linux和windows的,因此咱們如今windows下打開它。windows
直接點擊bat,打開jmeter:api
添加一個線程組:瀏覽器
添加完成以後,先設置這兩項:緩存
而後右擊左邊的線程組,添加一個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出頭,因此初步懷疑這是有性能問題的,最終反饋給開發,開發加入了緩存機制,而且增長了機器,通過優化以後,咱們再看看數據對比:
很明顯優化後的效果顯著,達到了預期的效果。
這就是我第一次簡單壓力測試的通過,看完後是否是你也能夠作了。