基准测试演示实例
現在我們已經知道了什么是基準測試,以及在基準測試中,所需要關注的指標都有什么,現在我們就來看一看進行一個具體的基準測試,所需要的步驟,首先我們要對我們的基準測試有一些規劃和設計,基準測試的設計呢,要可能的簡單,那這一步呢,我們要明確我們要采用的基準測試方式是哪一種,是對整個系統來進行基準測試呢,還是對某一個組件,比如對MYSQL進行基準測試就可以了,另外呢,還要確定我們要使用什么樣的數據,來進行基準測試,比如,我們希望基準測試呢,能夠反映出系統的基本情況,那么最好呢,就可以使用生產環境的實際數據,和所進行的SQL呢,來完成基準測試,如果我們要使用這種方式呢來進行測試的話,就要注意了,我們最好是利用生產環境數據庫的備份,以及在一定時間內,實際所產生的SQL日志,來運行這種多線程的回放,來完成這種測試,這種方式呢,相對來說是比較復雜,并且所要準備數據的時間呢,和測試時間呢都會比較長,而如果我們只想知道某個參數的調整,對我們數據庫性能的影響的話,就完全沒有必要這么麻煩,我們可以使用專門的測試工具來生成測試中所需要的數據和SQL,以此來完成我們的基準測試,這種方法呢比我們使用生產環境的數據呢,要更加的簡單,我們下面的演示中呢,也是使用第二種方法,在這一步中呢,還要計劃好,我們基準測試所要運行的時間和次數,通常情況下,如果我們對基準測試只運行一次,很短時間的話呢,我們想象的測試結果呢,是實時的,就是沒有任何參考意義的,我們只有多次測試之后,取得平均的測試結果,這樣才能反映我們系統的真實性能
那么第二步呢,就是要準備好在測試中,需要使用的測試數據,和一些系統狀態信息的收集腳本,對于測試數據的準備呢,前面我說過了,如果希望使用系統的真實數據的話,那么我們最好呢,要提前獲取真實數據的數據備份,以及在真實環境中,運行SQL的一個記錄,對于SQL執行的一個記錄呢,通常我們可以通過把慢查日志全部記錄下來的方式呢,來獲得,如果我們的測試沒有必要使用真實數據的話,一般的這種測試工具呢,都可以提供測試工具的生成,以及SQL腳本生成的功能,但是對于測試執行過程中,系統狀態收集的腳本,就需要我們自己來編寫了,正常情況下在執行一個基準測試時,我們需要盡可能多的呢,收集系統的當前信息,包括CPU使用率,磁盤IO,網絡流量的統計信息,以及MYSQL的innodb狀態的計數器信息的相關信息等等,這里呢,我為大家準備了一個腳本,大家可以根據腳本呢,再根據你的需求呢,來創建一個腳本,達到我們收集系統信息的目的,那么我們下面就來看看這個腳本
Get_Test_info.sh,就是我們信息收集的腳本,我們來看看這個腳本的內容vim Get_Test_info.sh我們來看看這個腳本很簡單,在前面兩行就定義了,腳本的運行間隔,每隔多長時間我就收集一下狀態信息,第三行我們就定義了,我們把我們的動態信息,收集到什么位置,就是記錄到什么目錄下,第四行就指定了一個運行標識,就是如果存在這個標識呢,就證明我們這個腳本在運行,如果你想停止這個腳本呢,可以通過刪除這個標識文件的方式呢來停止我們這個信息收集的腳本,第五行就是我們實際生成的運行標識的一個文件,第六行指定了我們MYSQL的命令行,MYSQL命令所在的位置,第七行就是記錄了運行了測試當前MYSQL系統的設置信息,從第八行開始,就是一個循環,這個循環呢只要在我們剛才所說的那個標識文件存在的情況下呢,就會一直的循環下去,第九行到11行呢,也就是定義了我們腳本的運行時間,文件名,還有我們每隔多長時間運行這個腳本,那么第13行呢,就收集到了我們系統的負載情況,并把它記錄到了一個文件中,第15行呢,是收集的是MYSQL的,全局的狀態信息,同樣的會把它記錄到一個文件中,第17行收集到的是innodb的狀態信息,第19行呢,收集到了MYSQL當前連接的線程的情況,涉及到了我們MYSQL在基準測試時系統信息
基本上就已經很全了,當然大家也可以根據自己的需要,在準備好我們需要的測試數據,以及系統收集腳本,我們就可以開始我們實際的測試了,由于我們的測試會多次執行,如果可以編寫腳本呢,多次測試的過程呢,肯定是最方便的,其實這個腳本很簡單,這里就不演示循環怎么編寫了,我們可以通過自己測試的步驟呢,編寫這個腳本,不過呢一定要注意,我們在這個腳本中呢,同時記錄下每次運行的信息,以便我們后面的分析使用,完成了基準測試呢,最后一步就是要對我們測試過程中,所收集的信息來進行分析,以便看我們的調整是否有效,在這個過程中呢,同樣需要自己編寫,相關的腳本,來進行更多信息的一種處理,并且最好可以通過圖形的方法呢來展示我們的測試結果,這里我也提供了一個簡單的測試腳本,我們先回來看一下vi analyze.sh
一共只有18行,這個腳本實際上呢,分析了我們剛才所收集的MYSQL全局狀態的信息的文件,并且取出了每一次,執行的間隔,間隔多長時間,并且打印出了我們當前系統的load值,以及這里查詢的數量,也就是說,每一次在MYSQL狀態信息中,所查詢的數量,通過兩次數量的差,除以時間間隔呢,可以得到我們剛才說的QPS,我覺得每秒鐘查詢的數量,這么一個統計結果,當然呢大家也可以根據你自己的需要來擴充這個腳本,我們可以把它改寫成來統計TPS,或者每秒插入量,刪除量,更新量的腳本,同時也可以通過MYSQL的狀態變量呢,知道我們每一次,運行這個參數時呢,并發量是什么樣子的,或者是線程量是多少,我們都可以通過這個腳本來完成那在進行具體演示之前呢,我們還要來看一下在基準測試中,我們需要注意的一些問題,只有避免了這些問題呢,我們的基準測試才是準確的,才能體現出我們的實際性能,我們在進行基準測試時呢,一定要注意以下幾個問題,這些問題呢,都有可能導致我們的基準測試不正確,首先第一個可能被我們忽視的問題呢,就是使用生產環境的真實數據進行基準測試時,我們只使用了真實數據的一個子集,而不是全部的生產環境數據,前面講解如何使用基準測試,我提到過,如果我們希望使用生產環境的數據,來進行基準測試,那最好是使用生產環境數據庫完全的備份,來進行測試,而不是人為的從全部數據中選擇出一小部分數據呢來進行測試,比如說我們的真實環境中,數據庫有幾百個G的數據,而我們在測試時呢,為了方便,人為的選擇了幾個G的子集,這樣進行測試呢,是不能真實的反映系統的情況的,而且我們認為的選擇了數據呢,不能完全體驗出,生產環境中真實數據的情況,這樣得出的結果呢,很可能是不正確的了,第二個被我們經常忽視的問題就是,在一個多用戶的場景中,我們只使用單用戶的模式來進行測試,比如我們的WEB應用,同時是大量用戶并發的使用場景,所以對于WEB應用呢,數據庫來進行基準測試時呢,一定要考慮到并發的情況,使用多個連接線程呢,MYSQL性能來進行測試,通常情況下,多線程的并發的數據庫性能,單線程數據庫訪問的表現是完全不同的,應用在單線程的時候呢,可能會應用的很好,但是一旦存在了并發的情況呢,就會出現大量的阻塞和死鎖,這些問題呢,在單線程的測試中呢,是無法發現的,所以我們要根據應用的實際情況,來進行我們測試的設計,而對于多用戶使用的場景呢,一定要使用多線程的并發測試,才能達到我們想要的目的,而另一個和上面有點類似的情況呢,分布式應用的性能,分布式的表現,跟單服務器是完全的不同的,比如我們的生產環境中,數據庫部署呢,可能使用的是主從同步,那么在進行基準測試時呢,也要使用相同的架構來進行測試,因為一方面來說,通常情況下,讀寫分離,所使用的中間層,會有性能損耗,如果我們在基準測試時,不考慮中間層的性能損耗,測試結果就很難用于預估我們生產環境中的性能,這時候我們就會發現,我們數據庫在基準測試環境,性能遠好于我們實際的生產環境,這樣存儲結果呢,也無法為我們的優化生產環境的性能呢,沒有任何的幫助,那么最后一個容易讓我們忽視的問題呢,在測試過程中呢,反復的執行同一個查詢,在真實的生產環境中,查詢肯定是不盡相同的,這可能會造成查詢緩存的命中率呢,比較低的情況,而我們在基準測試中,反復的使用相同SQL來查詢,那么在某種程度上來說呢,這個查詢可能完全會在緩存中命中,所以就無法真實的反應查詢的真實性能,以上就是我們在基準測試時呢,需要避免和注意到的一些問題
?
總結
