數據庫性能測試方案示例


 

前言 :
 
究竟怎樣進行數據庫性能測試,數據庫性能測試需要做些什么?大多數產品線的RD和QA也比較迷茫,經常過來咨詢。
 
一般說來,做數據庫性能測試需要如下幾個步驟:
1:明確測試目的
2:設計測試模型 (即壓力模型)
3:准備測試集群環境
4:准備壓力測試工具或者編寫壓力測試腳本
5:明確性能指標並加監控
6:根據2設計的測試模型准備測試數據
7:測試執行
8:測試分析
 
本文依據以上步驟,模擬測試需求- 多實例多盤數據庫的性能對比測試,制定測試方案公布給大家,方便大家了解數據庫性能測試。
 
多實例多盤數據庫性能測試方案
 
一、 測試目的
1. 對比數據庫單實例、多實例的在不同硬件設備上的性能情況。
2. 對比單機單實例和多實例的性能情況
3. 驗證網絡帶寬是否成為flash產品發揮性能優勢的瓶頸。
4. 驗證flash產品是否隨時間存在性能衰減的可能。
 
二、 測試方法概述
 
測試基准工具: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
 
三、 測試准備
測試環境准備
假設將四類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個表
說明:具體的測試庫表結構、類型
每張表的測試數據量等都需要根據具體測試目的和測試場景進行設計。
 
四、 測試步驟
 測試一: 不同集群配置,不同實例的性能對比測試
 
一: 數據構造,同時驗證各硬件集群基本讀、寫性能。
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,和響應時間分布。
(注意每一次測試命令中,涉及查詢條件的值隨機分布)
 
五、 總結:
關於數據庫性能測試,只要掌握了壓力測試工具。最關鍵的還是設計出符合業務的測試模型,以及測試完成后的測試分析。通過實踐抽象出測試模型,進行自動化,則測試過程可以事半功倍。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM