性能測驗目的
簡單來說：在復雜多變情況下，保證系統穩定
百度百科說：
- 評估系統的能力，測驗中得到的負荷和回應時間資料可以被用于驗證所計劃的模型的能力，并幫助作出決策，
- 識別體系中的弱點：受控的負荷可以被增加到一個極端的水平，并突破它，從而修復體系的瓶頸或薄弱的地方，
- 系統調優：重復運行測驗，驗證調整系統的活動得到了預期的結果，從而改進性能，
檢測軟體中的問題：長時間的測驗執行可導致程式發生由于記憶體泄露引起的失敗，揭示程式中的隱含的問題或沖突， - 驗證穩定性（resilience）可靠性（reliability）：在一個生產負荷下執行測驗一定的時間是評估系統穩定性和可靠性是否滿足要求的唯一方法，
性能測驗方案關鍵點
- 業務系統分析：根據業務和系統運維實際情況，分析TPS的時間分布圖、HPS/PV的時間分布圖
- 場景設計：根據實際的資料容量，業務型別比例，業務時段，業務量來綜合設計性能測驗場景，舉例來說，某APP在12點-14點是交易峰值，占用全天交易的80%，那可以抽取這個時間段內的業務型別比例，產生的比例是，登錄:加入購物車:交易:查詢訂單=10:3:1:6，那在做性能測驗場景設計的時候可以采用這一比例進行測驗，
- 監控模型建立：
服務器監控
資料庫監控
Docker監控
JVM監控Grafana
JVM監控VisualVM
- 性能問題分析和調優：
資料庫問題分析
堆記憶體泄漏排查
死鎖問題排查
JVM分析
Arthas調優工具
性能測驗通過標準
超時概率：小于0.5‰
錯誤概率：小于0.5‰
TPS：大于期望高峰值
CPU利用率：小于75%
回應時間：小于期望時間
Load負載：平均沒核CPU的Load小于1
JVM記憶體使用率：小于80%
FullGC頻率：平均大于半小時1次
性能測驗結果圖識別
TPS和回應時間曲線抖動不能過于強烈，具備一定梯度，整體趨勢應該是趨近與平穩
如下圖在執行緒數增加的時候，TPS一個比較正常的圖示，持續增加后，在13000TPS的位置趨近平穩，有一定梯度
如下TPS和回應時間的圖例，可以用作正常類參考
如下圖在執行緒數增加的時候，回應時間在1s一下緩慢增漲，當TPS到達高點13000以后，隨時執行緒持續增加，回應時間增速加劇
不太合理的TPS圖
波動幅度劇烈，找不到TPS的穩定峰值，不利于問題分析，性能測驗結果不準確
梯度不明顯，可以考慮增加Ramp-up，讓TPS增幅變緩，否則回應時間的圖也不會出現穩定期，較難做出峰值判斷
TPS在某些點有突然下降，需要做出排查
掃一掃，關注我
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/193634.html
標籤：其他