Categories
程式開發

性能壓測時,並發壓力增加,系統響應時間和吞吐量如何變化


性能測試

性能測試是性能優化的前提和基礎,也是性能優化結果的檢查和度量標準。不同視角下的網站性能有不同的標準,也有不同的優化手段。

主觀視角:用戶感受到的性能加載頁(先文字後圖片)客觀視角:性能指標衡量的性能

做性能優化的時候,一方面提高性能指標,另一方面要考慮到提高用戶的主觀感受(可以利用異步操作)。架構師訓練營不介紹主觀視角

性能測試指標

相應時間RT, Response Time:用戶感受到的時間(客戶端視角)。應用系統從發出請求開始到收到最後響應數據所需要的時間。直觀的反映了系統的快慢並發數:系統能夠同時處理請求的數目,系統的負載特性。對於網站而言,並發數即係統並髮用戶數,指同時提交請求的用戶數目。注意與在線用戶數(當前登錄系統的用戶數)和系統用戶數(可能訪問系統的總用戶數)的區別。一般來說,並發數不會太大,淘寶雙十一高峰並發數可能是百萬級別,可能同時在線數達到億級,用戶數可能超過十億。吞吐量:單位時間內系統處理的請求數量,系統的處理能力。對於網站,請求數/秒,頁面數/秒,訪問人數/天,處理的業務數/小時TPS, Transactions Per Second 每秒事務數性能計數器:描述服務器或操作系統性能的數據指標,包括System Load、對象與線程數、內存使用、CPU 使用、磁盤與網絡I/O 等指標。

其他常用指標:

RPS, Request Per Second:每秒請求數CPS, Codes Per Second:HTTP 返回碼每秒PV, Page View:頁面瀏覽量UV, Unique Vistor:獨立訪問者IP, Internet Protocal:獨立IP 數IOPS, Input/Output Operations Per Second 磁盤

吞吐量= ( 1000 / 響應時間ms) × 並發數

吞吐量Throughput 的討論需要有時間單位,一般採用Bytes/Second、Pages/Second 和Request/Second 等單位。

Bytes/Second 和Pages/Second 表示的吞吐量,受網絡設置、服務器架構、應用服務制約Request/Second 表示的吞吐量,受應用服務器和應用本身的製約

不同並髮用戶數場景下,即使系統具有相近的吞吐量,但是得到的系統性能瓶頸也不一樣。

比如100 個並髮用戶,每用戶每隔1 秒發出一個Request 和1000 個並髮用戶,每隔10 秒發出一個Request,兩個場景有相同的吞吐量100 Request/Second,但是兩個場景所佔用的資源不一樣,性能拐點也肯定不一樣。

性能壓測時,並發壓力增加,系統響應時間和吞吐量如何變化 1

性能測試方法

性能壓測時,並發壓力增加,系統響應時間和吞吐量如何變化 2

性能測試:以系統設計初期規劃的性能指標為預期目標,對系統不斷施加壓力,驗證系統在資源可接受範圍內,是否能達到性能預期負載測試:對系統不斷增加並發請求以增加系統壓力,直到系統的某項或多項性能指標達到安全臨界值,如某種資源已經呈飽和狀態,這時候繼續對系統施加壓力,系統的處理能力不但不能提高,反而會下降。壓力測試:超過安全負載的情況下,對系統繼續施加壓力,知道系統崩潰或不能再處理任何請求,一次獲得系統最大壓力承受能力。穩定性測試:在特定硬件、軟件、網絡環境條件下,給系統加載一定業務壓力,是系統運行較長一段時間,以此檢測系統是否穩定。在生產環境,請求壓力是不均勻的,呈波浪特性,因此為了更好的模擬生產環境,穩定性測試也應不均勻的對系統施加壓力。

性能壓測時,並發壓力增加,系統響應時間和吞吐量如何變化 3

究竟部署多少台服務器(資源)比較合適?是架構師需要考慮的一個決策,找到性能、價格的平衡點。架構師要清醒的知道,決策的依據到底是什麼,可能的代價是什麼,是否能夠承擔這個責任……

空閒區間:系統並髮用戶數比較少,吞吐量也低,系統處於空閒狀態線性增長區間:系統整體負載不大,隨著並髮用戶數增長,吞吐量也會隨之線性增長拐點:系統並髮用戶數進一步增長,系統處理能力趨於飽和,每個用戶的響應時間逐漸變長;系統整體吞吐量不會隨著並髮用戶數增長而繼續線性增長。過飽和區間:系統並髮用戶數繼續增長,系統處理能力達到過飽和狀態;如果繼續增加並髮用戶數,最終所有用戶的響應時間會變得無限長;系統整體吞吐量會降為零,系統處於被壓垮的狀態。

性能壓測時,並發壓力增加,系統響應時間和吞吐量如何變化 4

性能測試方法論,Quest Soft,2005年

性能壓測時,並發壓力增加,系統響應時間和吞吐量如何變化 5

在TPS 增加的過程中,響應時間一開始會處在較低的狀態,也就是在A 點之前。接著響應時間開始有些增加,直到業務可以承受的時間點B,這時TPS 仍然有增長的空間。再接著增加壓力,達到C 點時,達到最大TPS。我們再接著增加壓力,響應時間接著增加,但TPS 會有下降(請注意,這裡並不是必然的,有些系統在隊列上處理得很好,會保持穩定的TPS,然後多出來的請求都被友好拒絕)。最後,響應時間過長,達到了超時的程度。

——《02丨性能綜述:TPS和響應時間之間是什麼關係? 》 性能測試實戰30講

通常從兩個層面定義性能場景的需求指標:業務指標和技術指標。

所有的技術指標都是在有業務場景的前提下制定的,而技術指標和業務指標之間也要有詳細的換算過程。