【6】效能測試平臺從設計到實現-報告初步解讀和平臺的增強優化
在構建完任務後,開始進入到執行階段,目前我們還是以人工值守的方式來進行測試,通過觀察摘要和指標的變化來確定當前的效能測試是否符合預期,是否需要提前終止測試等操作
先來給大家看下我們的壓測執行中所做的事情,在中控系統的前端頁面中,我們給使用者按Tab展示了本次壓測任務的任務摘要,被測服務的實時監控【硬體指標及服務指標】、實時日誌【被測服務的錯誤日誌】和實時資料【引擎執行的實時資料視覺化看板】,如下圖所示:
本次我們主要講解和壓力源相關的任務摘要和實時資料這兩部分,首先來看下,任務摘要~
在任務只要的Tab頁下,我們給使用者呈現本次任務的概要資料,包括基於使用者壓力模型引數,計算得出的發起的請求總數、執行市場、已完成數、待完成數等。
其次,我們將每次請求的response以console列印日誌的方式,給到使用者,來對每次請求,進行檢視
同樣如果發生問題,我們會將錯誤型別的摘要顯示出來~
以數字形式呈現的摘要資訊,可以巨集觀定性的來看變化,但是如果想要實時進行統計分析,並基於此檢視趨勢的話,顯然數字摘要的形式不能滿足我們的需求,於是,我們參考了官方提供的實時監控的方案,基於Graphite+Influxdb+Grafana的方式來做實時資料的視覺化展示~,詳細方法參考文末資料
有了資料摘要和實時視覺化報告,可以方便QA同學判定當前測試過程是否符合預期,如果不符合預期,我們可以通過手動部分停止或一次停止全部壓力源的方式,來減少壓力或停止任務
最後,我們去歷史任務中來檢視本次任務的結果吧
哈哈 看看我們這次任務的彙總報告
至於具體的指標解讀,且聽下回分解~
參考資料:https://gatling.io/docs/gatling/guides/realtime_monitoring/
- 面試官:cglib為什麼不能代理private方法?
- 想看Dubbo原始碼?一定要先看一看這一篇!
- 死磕synchronized二:系統剖析延遲偏向篇一
- 架構與思維:高併發下解決主從延時的一些思路
- 道與術
- OopMap看不懂,怎麼調優哇
- Kafka 精妙的高效能設計(下篇)
- 一次tcp視窗被填滿問題的排查實踐
- 搶了個票,還以為發現了12306的系統BUG
- 微服務5:服務註冊與發現(實踐篇)
- 看一遍就理解:零拷貝詳解
- 分散式:分散式系統下的唯一序列
- 面試官:為什麼jdk動態代理只能代理介面實現類?
- 揭開記憶體屏障的神祕面紗
- 微服務4:服務註冊與發現
- 我就奇了怪了,STW到底是怎麼做到的
- 這樣使用 IDEA ,效率提升10倍!| IDEA 高效使用指南
- 從hotspot原始碼層面剖析Java的多型實現原理
- 垃圾回收全集之十二:GC 調優的實戰篇—Weak, Soft 及 Phantom 引用
- JVM的多型是如何實現的