經由上一篇討論過KPI的指標特性,接下來,讓我們分析測試結果來找到bottlenecks吧!
Graph 1 - No Bottlenecks
第一張圖顯示了系統超強穩定度:虛擬用戶數量增加,但平均回應時間不受影響。 表示這個系統沒有遇到任何bottlenecks,用戶體驗是一致的。
Graph 2 - Bottlenecks that Might Need Fixing
第二張圖可以發現在虛擬用戶數量逐漸上升時,平均回應時間也跟著上升,而且呈現不規則的波動。表示系統超過某個用戶數量時,系統的處理速度無法讓回應時間維持一定,這時候我們發現了瓶頸,不過,這個瓶頸一定需要被解決呢?其實這取決於產品經理的決策,如果上升的回應時間還在可接受範圍內則不需要被修改,不可接受則必須被修正。
Graph 3 - System Failure
第三張圖在虛擬用戶數量上升的同時,平均回應時間上升且錯誤也跟著逐漸上升,且每秒都在增加錯誤,這種巨大的瓶頸需要即時的被修復且持續的關注。
你也可以使用每秒點擊次數來查看這些圖表。 通過關聯每秒點擊次數,平均回應時間和每秒錯誤數量,確定是否找到瓶頸。
Number of Virtual Users (VU) and Hits per Second (Hit Rate)
以下圖表將VU的數量與每秒點擊數相關聯。 假設我們的系統要求為1,000個虛擬用戶每秒500個點擊次數。
Graph 4 - No Bottlenecks
圖表4顯示了一個穩定系統。 VU的數量對應每秒點擊次數500次,代表系統能夠管理VU數量的增長,而不會造成他們發送請求能力降低的問題。
Graph 5 - Bottlenecks that Need Fixing
第五張圖顯示了一個有瓶頸的系統。 每秒點擊次數隨著VU的數量而增加,但是達到期望的500次之前就停止上升。代表每個用戶只能執行較少的次數並且發送比我們的預期更少的請求。 這個瓶頸需要被修復。
Graph 6 - System Failure
第六個圖表顯示一個無法應付VU數量變化的系統。 每秒點擊次數上升,但隨後迅速下降。 最終跟著點擊次數的上升,錯誤數量也跟著上升。 代表VU超過某個數量後,所有的點擊都會發生錯誤。 在這種情況下用戶無法執行操作,因此系統有一個巨大的瓶頸,需要緊急的修理和持續的關注。
參考連結 : link
留言列表