摘要:當并發性增加時,需要測量吞吐量是否下降,響應時間是否變長可擴展性可擴展性不是壓力測試的指標,可擴展性指標對于容量規范非常有用,它可以提供其他測試無法提供的信息,來幫助發現應用的瓶頸歸根結底,應該測試那些對用戶來說最重要的指標。
簡單來說,基準測試是則很難對系統設計的一種壓力測試,通常的目標是為了掌握系統的行為。但也有其他原因。比如重現某個系統狀態,或者是做新硬件的可靠性測試。
因為基準測試是唯一有效方便的,可以學習系統在給定的工作負載下會發生什么的方法。系統測試可以觀察在不同壓力下的行為,評估系統的容量,掌握哪些是重要的變化,或者觀察系統如何處理不同的數據。
基準測試可以完成的工作:
基準測試的一個主要問題在于其不是真實壓力的測試。基準測試施加給系統的壓力相對真實壓力來說,通常會比較簡單,因為真實壓力是不可預期而且變化多端的,有時候情況會過于復雜而難以解釋。
那么基準測試和真實壓力不同在什么地方?
結論就是,我們只能進行大概的測試,來確定系統大致的余量有多少。當然也可以做一些真實的壓力測試,但在構造數據集和壓力要特別小心,而且這樣就不再是基準測試了。基準測試要簡單直接,結果之間相互容易比較
兩種主要策略:
針對測試整個系統做集成式測試而不是多帶帶測試的原因有以下幾點:
但是集成式測試很難建立,如果基準測試的設計有問題,那么結果就無法反映真實的情況,決策也可能是錯的。
所以有的時候不需要了解整個應用的情況,而只需要關注MySQL的性能,至少在項目初期可以這樣做,以下情況,可以選擇只測試MySQL:
另外,如果能夠在真實的數據集上執行重復的查詢,那么也是有用的,如果可能,可以采用生產環境的數據快照。不幸的是,設置一個基于真實數據的基準測試復雜而且耗時,而且開發一個新應用,只有很少的數據量,如果想要測試規模擴張后的性能表現,只能通過模擬大量的數據和壓力進行
不同的指標需要用不同的方法測試
以下指標:
歸根結底,應該測試那些對用戶來說最重要的指標。因此應該盡可能地去收集一些需求,然后基于這些需求去設計基準測試
以下是測試的常見錯誤
設計和規劃基準測試
標準的基準測試,應該確認選擇了合適的測試方案
設計專用的基準測試是很復雜的,往往需要一個迭代的過程。首先需要獲得生產數據集的快照(很容易還原),然后,針對數據運行查詢(選擇一個有代表性的時間段,如果時間段選擇比較小,則可以選擇多個時間段,這樣有助于覆蓋整個系統的活動狀態)
3.可以在不同級別記錄查詢
4.即使不需要創建專用的基準測試,也要寫下測試規劃(測試數據,系統配置步驟,如何測量和分析結果,以及預熱的方案)
5.寫一些腳本分析測試結果
基準測試應該運行足夠長的時間,這一點非常重要,應當在穩定狀態下測試并觀察
一個常見的錯誤測試方式是,只執行一系列短期的測試。這種不花費足夠時間去完成準確完成的基準測試,那么已經花費的所有時間都是一種浪費,所以有時候要相信別人的測試結果,并使用
可以編寫一個shell腳本來記錄測試結果,配置文件,測試指標,腳本和其他相關說明都保存在其中
首先,獲得準確測試結果的最好辦法,是回答一些關于基準測試的基本問題:
然后,確認測試結果是否可重復,每次測試之前都要確保系統的狀態一致
如果測試過程會修改數據或者schema,那么每次測試前,需要利用快照還原數據
每次測試時修改的數據應該盡可能地小,一般情況下都是通過迭代的方式
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/119610.html
閱讀 1318·2021-11-24 09:38
閱讀 3256·2021-11-22 12:03
閱讀 4156·2021-11-11 10:59
閱讀 2317·2021-09-28 09:36
閱讀 1032·2021-09-09 09:32
閱讀 3411·2021-08-05 10:00
閱讀 2527·2021-07-23 15:30
閱讀 2973·2019-08-30 13:12