數據庫性能測試方案示例

 

前言 ：
 
究竟怎樣進行數據庫性能測試，數據庫性能測試須要作些什麼？大多數產品線的RD和QA也比較迷茫，常常過來諮詢。
 
通常說來，作數據庫性能測試須要以下幾個步驟：
1：明確測試目的
2：設計測試模型 （即壓力模型）
3：準備測試集羣環境
4：準備壓力測試工具或者編寫壓力測試腳本
5：明確性能指標並加監控
6：根據2設計的測試模型準備測試數據
7：測試執行
8：測試分析
 
本文依據以上步驟，模擬測試需求- 多實例多盤數據庫的性能對比測試，制定測試方案公佈給你們，方便你們瞭解數據庫性能測試。
 
多實例多盤數據庫性能測試方案
 
1、 測試目的
1. 對比數據庫單實例、多實例的在不一樣硬件設備上的性能狀況。
2. 對比單機單實例和多實例的性能狀況
3. 驗證網絡帶寬是否成爲flash產品發揮性能優點的瓶頸。
4. 驗證flash產品是否隨時間存在性能衰減的可能。
 
2、 測試方法概述
 
測試基準工具:smart-slap(mysqlslap)，Jmeter模擬若干客戶端、若干用戶執行指定的SQL語句，訪問數據庫。同時，經過監控工具監控系統負載、mysql數據庫的服務，全面瞭解數據庫系統以及硬件的負載狀況。
 
href=」http://qa.baidu.com/blog/wp-content/uploads/2013/03/b1.JPG」>
 
測試模型
測試監控及結果統計
監控工具統計以下信息，分析性能瓶頸。
 
系統負載：
CPU:CUP_IDLE 、CPU_WA、SERVER_LOADAVG
內存：MEM_URATE、MEM_USED
網卡：NIC_TOTAL_IN、NIC_TOTAL_OUT、
數據庫負載：
QPS:COM_READS、COM_WEITES
主從延遲：SECOND_BEHIND_MASTER
慢查詢：SLOW_QUERIES_PT
鏈接數：THREADS_CONNECTED、THREADS_RUNNING
 
STL-tools 監控集羣負載
 
附：性能指標：
 
系統負載：
CPU:CUP_IDLE 、CPU_WA、SERVER_LOADAVG
內存：MEM_URATE、MEM_USED
網卡：NIC_TOTAL_IN、NIC_TOTAL_OUT、
 
數據庫負載：
QPS:COM_READS、COM_WEITES
主從延遲：SECOND_BEHIND_MASTER
慢查詢：SLOW_QUERIES_PT
鏈接數：THREADS_CONNECTED、THREADS_RUNNING
 
3、 測試準備
測試環境準備
假設將四類IO存儲設備，進行單、多實例的性能測試對比。則能夠部署測試集羣以下：
 

 
測試集羣具體搭建:
2臺機器 ——–4主4從
根據測試更換硬件：
RAID+SAS：
RAID+SSD:
Flash :
Fusion :
 
監控：在每臺機器上部署數據庫監控腳本monitor,最好有統一平臺上調度、管理、分析monitor採集到的數據。
 
測試工具準備：

Smart-slap :
特色：全量發壓力，可獲得最大QPS，對比不一樣集羣的最大QPS。分析不一樣集羣的最大QPS.
 
Jmeter:
特色：控制實時壓力，分析各集羣在指定壓力下的性能狀況。
 
測試思路：
 先採用slap進行對不一樣集羣組合進行一樣的sql壓力。(壓力時間)取得不一樣集羣的最大QPS，進行對比。
取最大QPS的必定比率(如1/8倍,1/4倍,1/2倍,1倍)做爲每秒發送的請求壓力進行測試。比較各個集羣的負載、數據庫性能狀況。
 
網絡瓶頸測試：
同網段3臺壓力機器 往一個集羣壓足夠多的IO壓力。分析各個硬件的IO。磁盤、CPU比網卡提早到達壓力閥值說明網卡不是瓶頸。若網卡IO先達到極限則說明網卡存在瓶頸。
 
硬件性能衰減測試
一樣壓力測試24小時，比較最初1小時，和最後1小時的 TPS.以及各項性能指標。
 
測試數據準備：
數據庫： flashT
 
36張表：
 Test1- test36 :
 表結構：
CREATE TABLE `test1` (
`doc_id` int(10) unsigned NOT NULL default ’0′,
`main_status` tinyint(3) unsigned NOT NULL default ’0′,
`sub_status` tinyint(3) unsigned NOT NULL default ’0′,
`create_time` int(10) unsigned NOT NULL default ’0′,
cid1` smallint(5) unsigned NOT NULL default ’0′,
……………
PRIMARY KEY (`doc_id`)
);
數據量：
每一個表達到5000W 行(大概30G)
36個表
說明：具體的測試庫表結構、類型
每張表的測試數據量等都須要根據具體測試目的和測試場景進行設計。
 
4、 測試步驟
 測試一： 不一樣集羣配置，不一樣實例的性能對比測試
 
一： 數據構造，同時驗證各硬件集羣基本讀、寫性能。
1) 4個實例所有開啓insert 5000W ;初步對比寫性能.
用36個slap併發實例分別往36張表insert，往每一個表插入5000W 行數據。
2) 4個實例所有開啓，每張表20個select併發select。初步對比讀性能。
用36個slap併發實例子每一個實例20個併發select請求分別從36張表中取數據。
 
二：對比不一樣集羣執行最經常使用SQL命令的性能狀況
制定數據庫系統最經常使用的SQL語句，數據庫執行這些SQL語句的性能。用slap併發用戶數從10，50，100，200。
 
三：對比不一樣集羣處理最耗時SQL命令的性能狀況
制定數據庫系統最耗時的SQL語句，數據庫執行這些SQL語句的性能。用slap併發用戶數從10，50，100，200。
 
四：模擬事務處理，對比各集羣性能狀況。
 模擬事物，，用slap併發用戶數10，50，100，200，500，800，1000分析不一樣集羣分別在多少併發用戶數下，TPS值最大。
 
五：分析各集羣在線事物處理能力。
 模擬事務處理，根據步驟四獲得的最大TPS,設置TPS的必定比率做爲每秒事務數，用jemeter測試，併發，10,50,100,200,500,800,1000.分析各個併發各類集羣下的響應時間分佈和其餘各項性能指標。分析TPS狀況最好的併發數。
 
測試二：網卡瓶頸測試
 
步驟一:分析測試一中的各項測試結果的CPU、磁盤、網卡等負載狀況。
若是其餘幾項比網卡提早到達瓶頸。則說明網卡不會成爲瓶頸。相反進入步驟二。此外，若是測試一中的各項測試磁盤，網卡，CPU等均未達到瓶頸。則將測試一中的步驟四，增大併發壓力，直到出現負載瓶頸。
 
步驟二：調整測試。
 
測試三：硬件是否衰減狀況。
 
步驟：用jmeter 持續測試24小時。
用測試一中的步驟五獲得的最好TPS的併發數做爲這次測試的併發數，用Jmeter併發測試24小時，分析第一個小時和最後一個小時的TPS,和響應時間分佈。
（注意每一次測試命令中，涉及查詢條件的值隨機分佈）
 
5、 總結：
關於數據庫性能測試，只要掌握了壓力測試工具。最關鍵的仍是設計出符合業務的測試模型，以及測試完成後的測試分析。經過實踐抽象出測試模型，進行自動化，則測試過程能夠事半功倍。