效能測試中,TPS和RT之間的關係,你知道嗎?
引言
在開始今天的內容講解之前,我們應該回顧一下,在我的全鏈路壓測專欄中的第一篇,我就已經介紹了當前的效能測試在網際網路企業中的重要性,已經效能在網際網路行業中的佔比是多少。 加我VX:atstudy-js 回覆“測試”,進入 自動化測試學習交流群~~
這個時候是不是會有同學問我, 你已經寫過全鏈路壓測的專欄,為什麼還要寫這個效能專欄呢?難道效能專欄和全鏈路壓測專欄沒有公用的地方嗎?答案是肯定的。
效能工程與全鏈路壓測工程之間的共同點很明確,就是壓測;而區別點也明顯,即線上/線下、生產資料/測試資料。
看到這裡,是不是還有同學有疑問,既然有區別,那就把區別列出來好了,幹嘛還要專門整一個專欄來寫效能工程的文章呢?這次寫出來的內容,會不會有重複的地方呢?
這一點需要你放心,我既然寫效能工程專欄的內容,肯定是不會跟全鏈路壓測專欄有重複。
全鏈路壓測,是透過真實生產環境的資料進行改造,雲伺服器搭建;
效能工程,是透過物理伺服器的搭建,使用的是非生產環境的資料。
說了這麼多,我們就言歸正傳,來聊一聊效能測試中,TPS和RT之間的關係。
我想但凡瞭解或者做過效能測試的同學,都知道TPS與RT。但是,TPS和RT之間的關係,可能沒有幾個人能說清楚。或者說專職從事效能測試7年以下的同學,很少會完全理解(掌握)TPS和RT之間的關係,已經如何根據TPS與RT之間的關係,來判斷系統的瓶頸點。
TPS與RT
我先上一張圖,這張圖,學習效能測試的同學,估計印象深刻。
在這個圖中,定義了三條曲線、三個區域、兩個點以及三個狀態描述。
1、三條曲線:吞吐量的曲線(紫色)、利用率(綠色)、響應時間曲線(深藍色)。
2、三個區域:輕負載區(Light Load)、重負載區(Heavy Load)、塌陷區(Buckle Zone)。
3、兩個點:最優併發使用者數(The Optimum Number of Concurrent Users)、最大併發使用者數(The Maximum Number of Concurrent Users)。
4、三個狀態描述:資源飽和(Resource Saturated)、吞吐下降(Throughput Falling)、使用者受影響(End Users Effected)。
我在很多地方,都看到了對這張圖的引用。應該說,做為一個示意圖,它真的非常經典,的確描述出了一個基本的狀態。
但是,示意圖也只能用來做示意圖,在具體的專案中,我們仍然要有自己明確的判斷。我們要知道,這個圖中有一些地方可能與實際存在誤差。
首先,很多時候,重負載區的資源飽和,和 TPS 達到最大值之間都不是在同樣的併發使用者數之下的。
比如說,當 CPU 資源使用率達到 100% 之後,隨著壓力的增加,佇列慢慢變長,響應時間增加,但是由於使用者數增加的幅度大於響應時間增加的幅度之前,TPS 仍然會增加,也就是說資源使用率達到飽和之後還有一段時間 TPS 才會達到上限。
大部分情況下,響應時間的曲線都不會像圖中畫得這樣陡峭,並且也不一定是在塌陷區突然上升,更可能的是在重負載區突然上升。
另外,吞吐量曲線不一定會出現下降的情況,在有些控制較好的系統中會維持水平。曾經在一個專案中,因為 TPS 維持水平,並且使用者數和響應時間一直都在增加,由於響應時間太快,一直沒有超時。
最優併發數這個點,通常只是一種感覺,並沒有絕對的資料用來證明。在生產運維的過程中,其實我們大部分人都會更為謹慎,不會定這個點為最優併發,而是更靠前一些。
最大併發數這個點,就完全沒有道理了,效能都已經衰減了,最大併發數肯定是在更前的位置呀。
這裡就涉及到了一個誤區,壓力工具中的最大使用者數或執行緒數和 TPS 之間的關係。
在具體的專案實施中,有經驗的效能測試人員,都會更關心服務端能處理的請求數即 TPS,而不是壓力工具中的執行緒數。
這張圖沒有考慮到鎖或執行緒等配置不合理的場景,而這類場景又比較常見。也就是我們說的,TPS 上不去,資源用不上。所以這個圖預設了一個前提,只要執行緒能用得上,資源就會蹭蹭往上漲。這張圖呢,本來只是一個示意,用以說明一些關係。但是後來在效能行業中,有很多沒有完全理解此圖的人將它做為很有道理的“典範”給一些人講,從而引起了越來越多的誤解。
在我的工作經驗中,其實在 saturation point 之前,效能指標就已經可以顯示出問題了,並且已經非常 panic 了,而我們之所以接著再加壓力是為了讓指標顯示得更為明顯,以便做出正確的判斷。而調優實際上是控制系統在飽和點之前,這裡有一個水位的問題,控制容量到什麼樣的水位才是效能測試與分析的目標。
最後:
可以到我的個人V:atstudy-js,可以免費領取一份10G軟體測試工程師面試寶典文件資料。以及相對應的影片學習教程免費分享!其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、介面測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、介面自動化測試、測試高階持續整合、測試架構開發測試框架、效能測試等。
這些測試資料,對於做【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫,這個倉庫也陪伴我走過了最艱難的路程,希望也能幫助到你!
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31407649/viewspace-2912640/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 思考 TPS 與 RT 之間的關係
- 這些著名資料庫之間的“關係”,你知道嗎?資料庫
- 效能測試各個指標之間關係指標
- TPS和響應時間之間是什麼關係
- 效能測試中如何確定TPS和併發數
- 效能測試工具你知道多少?
- 你不知道的JavaScript——效能測試和調優JavaScript
- 併發使用者數與TPS之間的關係
- FAILGROUP和REDUNDANCY之間的關係關係!AI
- 效能分析之使用者數(執行緒數)/響應時間/TPS的關係執行緒
- 關於壓力測試中 TPS 和併發數的思考
- 黑盒測試和白盒測試的關係
- 軟體測試這些你知道嗎?
- UML中類之間的關係
- tablespace和datafile之間的關係
- 服務端效能測試你應該知道的服務端
- Android 中Activity,Window和View之間的關係AndroidView
- 自動化測試和資料驅動之間的關係,十分鐘帶你弄清楚
- 第三方軟體測評▏web測試和app測試的區別你知道嗎?WebAPP
- QT中類之間的關係圖QT
- Window, WindowManager和WindowManagerService之間的關係
- 效能測試的分類、區別以及特點這些你都知道了嗎?
- 測試表的空間壓縮與表空間的關係
- 大話UML中類之間的關係
- CSS系列:CSS中盒子之間的關係CSS
- 效能測試工具Jmeter你所不知道的內幕JMeter
- 類之間的關係
- 持續測試跟自動化測試的這些區別你知道嗎?
- 黑客和開源革命之間的關係黑客
- 專案管理中各系統之間的關係專案管理
- 效能測試工具LoadRunner你所不知道的內幕
- 網站和伺服器之間的關係網站伺服器
- 如何理解Nginx、uWSGI和Flask之間的關係?NginxFlask
- SDK、JDK、JRE 和JVM 之間的關係JDKJVM
- 【java】類之間的關係Java
- 你知道MySQL的Limit有效能問題嗎MySqlMIT
- 作為一個軟體測試新手,你知道軟體測試的幾個方向嗎?
- Python中is和==的區別有多大,你知道嗎?Python