百度不到的效能測試技巧-TPS 衰減快速分析
如何識別TPS拐點
先看一下這張圖。它聚合了響應時間,TPS,活動執行緒三個效能指標的監聽。注:這張圖上的效能指標都是以執行時間來作為單位的
從圖上能看出來幾個趨勢
1:負載是不斷越高的,最終會達到300併發
2:tps上升到900之後,就不再增加了,並長期保持在900左右
3:執行一段時間之後,響應時間開始升高,但是趨勢不明顯
問題來了
TPS曲線起起伏伏的,但是也還算穩定。有的朋友會認為還沒有到達瓶頸點,可以繼續加壓。那麼到底有沒有到達瓶頸點呢?
分析
瓶頸點到底怎麼分析?其實用下面的原則就可以判斷出來
在負載逐漸升高的情況下,tps卻長期不變。這並不是說明效能很穩定,而是說明我們的單執行緒tps是在逐漸下降的(單位時間總tps/活動執行緒)。
再分析響應時間,我們的響應時間其實也是在逐漸升高,從側面反映出執行緒的tps是在下降的。
但是具體在多少負載量的時候我們的瓶頸點已經到達?這張圖上不好計算,我們換一個監聽器
Transaction Throughput vs Threads
這個監聽器有兩個指標,縱座標是執行緒tps總數,橫座標是活躍執行緒數。記住這兩個哦~
我們通過這張圖可以看出,隨著活躍執行緒數的不斷增加,執行緒總tps會達到一個相對的最高點,然後開始下降。也就意味著我們的單執行緒tps開始衰減
總結
效能是否衰減,是通過單執行緒tps來判斷的。當我們的負載持續升高的時候,如果tps不再增加,說明效能已經開始衰減,此時的負載可以稱之為最優負載。如果繼續增加負載,tps反而會出現下降的趨勢,接著伺服器會出現異常,負載達到極限值,此時的負載稱之為最大負載
相關文章
- 【效能測試】常見的效能問題分析思路(二)案例&技巧
- 效能測試中TPS上不去的幾種原因淺析
- 效能測試中如何確定TPS和併發數
- 效能測試中,TPS和RT之間的關係,你知道嗎?
- 10、路由衰減路由
- Kafka效能測試分析Kafka
- WebGPU效能測試分析WebGPU
- 基於目標TPS的效能測試,如何通過手動設定場景進行測試?
- 效能測試報告編寫技巧測試報告
- 百度壓測,分析效能拐點
- 淺談效能測試分析
- 效能測試之測試分析與調優
- 效能測試連載-需求分析
- Akka.net 效能測試兼使用小技巧
- 效能測試之JVM的故障分析工具VisualVMJVMLVM
- ArrayBlockingQueue 和 LinkedBlockingQueue 效能測試與分析BloC
- 搭建 nGrinder 效能測試平臺並快速使用
- 測試生存指南!如何在快速迭代的專案中減少返工?
- 如何學習效能測試?LoadRunner小技巧集錦
- PR效能測試工具升級到全鏈路效能測試與分析平臺
- 【效能調優】效能測試、分析與調優基礎
- 效能狗(Perfdog)測試與資料分析
- 【效能測試】常見的效能問題分析思路(一)道與術
- 實用技巧:快速定位Zuul的效能瓶頸Zuul
- 阿里雲EMAS移動測試|快速掌握移動端相容性測試技巧阿里
- 樹莓派 redis 壓力測試 QPS 和 TPS樹莓派Redis
- 已安裝電纜裝置-多模衰減測量的國際標準
- 測試計劃&效能測試分析報告模板(僅供參考)
- Rust效能分析之測試及火焰圖,附(lru,lfu,arc)測試Rust
- 效能測試的流程
- 效能測試-服務端瓶頸分析思路服務端
- 百度影片在Android和iOS端效能測試方法AndroidiOS
- 關於壓力測試中 TPS 和併發數的思考
- 效能測試
- 介面測試和效能測試的區別
- Jmeter介面測試+效能測試JMeter
- 功能測試、自動化測試、效能測試的區別
- 小白測試系列:介面測試與效能測試的區別