每次效能測試跑完,報告裡會冒出一堆圖:回應時間、throughput、錯誤率、CPU、記憶體……新手常常一打開就被淹沒,不知道從哪張看起。我的建議很簡單:先看 User Graph。
User Graph 是一張記錄「測試過程中,到底有多少使用者同時掛在系統上」的圖。它在不同工具裡有不同名字,但講的是同一件事:
- LoadRunner 叫它 Running Vuser Graph
- JMeter 叫它 Active Threads Over Time
- NeoLoad 叫它 User Load Graph
名字不一樣,看法一樣。
這張圖在回答什麼
User Graph 之所以該第一個看,是因為它把整場測試的「負載長相」攤在你面前。光是這一張,就能回答幾個關鍵問題:使用者是從哪個時間點開始上線的?上升(ramp-up)跟下降(ramp-down)的節奏長什麼樣?穩定期(steady-state)從幾分幾秒開始?某個時間點上面到底有幾個人?最後使用者又是什麼時候退場的?
換句話說,你設計負載模型的時候在工具裡畫的那條曲線,跑出來到底有沒有照你想的方式發生,看這張圖就知道。特別是跑 step-up 或 spike 測試的時候,runtime viewer 裡的 User Graph 會即時畫出實際的負載曲線,你可以當場跟原本設計的 workload model 對照。對不起來,代表腳本的 pacing、think time 或排程設定有問題,先別急著看後面的數字。
兩個軸怎麼讀
這張圖很單純。X 軸是經過時間,可能是相對時間(從 0 開始算)或實際時鐘時間,看你工具的設定;它同時也標出整場測試的總長度。Y 軸就是使用者數量,也就是負載量。
看圖的時候把游標移到曲線上,就能讀到某個時間點實際在線的人數。重點是去對三段:ramp-up 是人數慢慢往上爬的階段,steady-state 是所有人都上來、人數維持水平的階段,ramp-down 是人數慢慢退場的階段。
圖一:一般負載測試的 User Graph,穩定期是一條水平線。
這裡有個常被忽略的細節:一般的 load test,穩定期應該是一條水平線;但如果你跑的是 stress test,負載會一階一階往上加,曲線會呈現持續往上的斜線,而不是平的。所以看到斜線不一定是出錯,要先確認你跑的是哪一種測試。
圖二:壓力測試會持續加壓,曲線呈階梯式上升。
真正拿來分析效能的,是 steady-state 這一段。Ramp-up 跟 ramp-down 期間系統還在暖機或收尾,數字波動大,通常可以略過不看。
這張圖真正的價值:疊圖
User Graph 單看很簡單,但它的威力在於拿來跟別的圖疊在一起。負載是因,其他指標是果,把因果放在同一個時間軸上,瓶頸就會自己跳出來。
疊回應時間圖
看人數往上加的時候,回應時間有沒有跟著惡化。要特別留意一種狀況,回應時間拉長到使用者受不了、開始中途退出測試。如果你在 User Graph 看到人數不正常地往下掉,而你的腳本並沒有設計退場,那很可能就是逾時或錯誤把人踢出去了,這是個危險訊號。
圖三:人數維持高點時回應時間開始爬升,代表系統逼近瓶頸。
疊 throughput 圖
在穩定期、人數固定的情況下,throughput 理論上應該維持一個平穩規律的形狀。如果人數沒變,throughput 卻突然暴衝或塌陷,代表伺服器端的處理出了狀況,值得追下去。
疊錯誤圖
把 User Graph 跟每秒錯誤數疊在一起,你可以很精準地抓出第一個錯誤是幾分幾秒發生的、錯誤又持續到什麼時候。這裡有兩個常見的判讀:如果錯誤是在 ramp-up 階段、隨著人數上升才開始增加,通常代表這是負載造成的錯誤;但如果錯誤是在穩定期中段、人數沒再增加的情況下才冒出來,那比較像是伺服器端開始塞車(大量請求堆積在後端來不及處理),或是其他伺服器層面的問題。
圖四:人數沒再增加卻冒出錯誤,偏向伺服器端塞車。
最後提醒一句
看到一條怪曲線、一個錯誤尖峰,先別急著下結論說系統撐不住。User Graph 給你的是線索跟時間點,不是答案。把相關的分析圖一起攤開,交叉比對,把根因找出來再寫進報告,這才是效能測試真正在做的事。 下次拿到測試結果,先打開 User Graph,確認這場測試真的有照你設計的方式跑,再往下分析。順序對了,後面省很多力氣。
發表迴響