如何进行基准测试
前面我們介紹了什么是基準測試,根據前面的定義我們可以知道,對MYSQL進行基準測試呢,主要是為了達到以下的目的,首先呢是建立MYSQL服務器的性能基準線,這主要是為了測試MYSQL的服務器的當前運行情況,如果是不清楚當前的性能,我們就無法確認某些優化的實際產生的效果會是怎樣,同時我們也可以利用歷史基準測試的結果呢,來分析,診斷一些性能中出現的一些問題,那么基準測試的第二個目的呢,就是模擬比當前系統更高的負載,以找出系統的壓力增加,而可能找到的一種系統瓶頸,通常是我們在有一定數據量的情況下,不斷地增加數據庫的并發,觀察QPS,TPS的變化,以判斷數據庫當前的配置的多少并發情況下是最好的,但是一旦超過了某個并發,可能就會出現性能下降的情況,基準測試還可以幫我們測試不同的硬件,軟件和操作系統,配置的情況下,數據庫的性能,比如RAID5,RAID10,那種更適合我們當前的系統,如果系統從機械硬盤升級到SSD這種的負載存儲,對隨機系統有什么幫助,Linux下不同的分區格式,和數據庫性能是否會有影響,升級MYSQL的版本是否能夠改善性能,對當前數據采用不同的引擎,會對我們的系統會有什么樣的影響,所有這類問題呢,我們都可以通過基準測試來解決,最后呢我們還可以通過基準測試證明我們新采購的硬件設備,是否配置是正確的,在新的硬件系統,就是上線到生產環境之前呢,我們一定要對這個新的系統進行基準測試,這不僅可以幫助我們了解新的硬件系統的性能基本線,還可以幫助我們測試當前新的系統,是否存在是否由于配置錯誤,而造成性能不如我們預期的情況的發生
那么接下來我們看看如何進行基準測試,通常來說,基準測試有兩種常見的方法,一種方法是對整個系統進行基準測試,這種方法呢,一般是從系統的入口進行測試,比如對于網站來說,通常是從WEB前端來進行測試,比如手機APP來說呢,通過APP的前端來進行測試,這種方法的優點在于,能夠測試整個系統的性能,包括WEB服務器,程序代碼,網絡,緩存服務器和數據庫,等等這些組件,這一點通常來說,是非常重要的,因為我們所關心的呢,并不僅僅是MYSQL服務器的性能,相比于數據庫呢,我們通常更關心整個系統的性能是怎樣子的,所以呢,對于整個系統進行整體的測試呢,直接反映出,我們所關心的各種新能問題,另外呢,從另一方面來說,MYSQL也并非總是系統性能產生這個問題的瓶頸,如果我們只關注MYSQL,可能會忽略其他組建的性能問題,所以說,對整個系統進行基準測試呢,第二個優點就是,能夠反映出系統中各個組件接口間的性能問題,體現真實的性能狀況,雖然對系統進行整體測試有很多的有點,但是其缺點也是不容忽視的,下面我們就來看他的缺點,我們前面提到過,基準測試最重要的就是要簡單,因為我們在系統優化的時候,可能要對不同的基準測試方案進行基準測試,以找出最好的解決方法,所以基準測試進行的時間要短,否則我們要花大量的時間來進行基準測試,所以對整個系統進行基準測試呢,這種方法的缺點就是,測試設計的比較復雜,完成一次測試耗費的時間也會很長,通常完成一次對整個系統的性能測試呢耗費幾天的準備時間是挺正常的
基準測試的第二種方法呢,單獨對某一個組件進行基準測試,特別是在一些時候,你并不需要對整個系統呢,進行基準測試的情況下,那么呢使用這種測試呢,單獨對組件進行基準測試呢,這種方式可能更加的合適了,比如我們只更新了MYSQL服務器的硬件,或者對于一些MYSQL中的索引啊,SQL進行了優化,這時我們就只需要單獨對MYSQL進行必要的基準測試就可以了,從對整個系統進行基準測試呢,是一樣的,這種方法也有其優缺點,我們先來看看單獨對MYSQL進行基準測試的優點都有什么,首先這種方法的優缺點呢,正好對和整個系統進行基準測試的這種優缺點是相反的,尤其是對于有點來說,他的優點呢就是測試方法設計呢通常比較簡單的,相對于測試所耗費的時間呢,也會更短,比較適合用于不同的數據結構啊,查詢性能的差異,或者具體應用的某個問題來進行測試,那么當前其缺點呢,也是顯而易見的,就是由于我們單純對MYSQL進行測試,所以必然無法全面的了解整個系統的性能基準線,也無法體現出系統中不同組件及接口之間的性能問題,以上就是我們基準測試常用的兩種方法,我們還要知道測試了哪些內容才能反映出性能狀態,以及使用什么樣的工具和方法來進行測試,由于我們在這里討論的是對于MYSQL的進行性能優化,所以呢我們就以第二種測試方式,也就是單獨對MYSQL來進行基準測試的方法呢,來給大家介紹具體的基準測試的方法和工具,以方便大家呢,對優化后的MYSQL進行測試,下面我們先來對MYSQL性能基準測試常用的指標是有哪些
對于MYSQL數據庫來說呢,常見的測試指標呢,大家多少呢也會聽過一些,比如單位時間內所處理的事務量,和查詢數量,這兩個指標呢主要用于衡量數據庫的吞吐量,我們大家所熟悉的數據庫,每秒處理的事務量,TPS,和數據庫每秒處理的查詢量QPS,就是這類指標的具體體現,對于相同數據量的相同SQL進行測試呢,如果調整后的TPS量,和QPS量有明顯的增長,那我們的調試呢,是成功的,否則我們就要考慮我們的優化方法呢,是否正確,響應時間是另一個采用的基準測試指標,這個指標用于衡量完成一個測試任務所花費的總體的時間,一個測試,通常會包括很多的測試項,這在我們對一個SQL進行測試,通常也會對這個SQL執行很多次,那么具體的測試情況和測試是不同的,這個響應時間單位也可能是微秒,毫秒,秒,或者是分鐘,當然呢也可能是小時,根據不同的時間單位,我們可以計算出,每一次的平均響應時間,最小響應時間,以及最大響應時間,和各個時間響應所占的百分比,通常這些統計指標,通常來說呢,最大的響應時間呢對我們的意義并不大,因為隨著測試時間的加長,最大響應時間也會越來越大,對我們比較有意義的呢,應該是百分比響應時間,例如說吧,一個SQL,百分之九十的響應時間呢,是在10毫秒,那么我們就可以認為這個SQL呢,在正常情況下,他的響應時間就是10毫秒,而超過10毫秒的情況呢,可能是會出現了一些意外,比如一些鎖啊,這種情況造成的響應時間加長,那么另外一個基準測試的重要指標呢,就是并發請求的數量,這個指標經常會和系統的連接數量想混淆,比方說,對于網站應用來說,這個指標會被經常表示成,有多少用戶在同一時間瀏覽一個WEB網站,通常會以WEB服務器的會話量來表達這個指標,實際上就是不正確的,比如我們會經常看到一個比較大的論壇,會顯示同時在線的人數呢,有幾千甚至上萬,但這并不代表,并發數量就有這么多,一方面對于大多數用于來說,只是簡單地瀏覽WEB頁面上顯示的信息,這并不等于WEB服務器的并發性,另一方面呢,服務器的并發量呢也并不等同于數據庫的并發量,即使WEB服務器有幾千上萬的會話,到MYSQL端呢,并發可能只有幾十個,甚至可能會更少,后面我們可能會告訴大家,如何獲取MYSQL服務器的并發情況,在這里大家要知道,并發量基準測試呢,需要關注的是正在工作中的并發的操作數,或者是同時工作的數量,而不是由多少連接的線程就可以了
?
總結
