前言： 究竟怎樣進行數據庫性能測試，數據庫性能測試需要做些什么？大多數產品線的RD和QA也比較迷茫，經常過來咨詢。
一般說來，做數據庫性能測試需要如下幾個步驟：
1、明確測試目的
2、設計測試模型 （即壓力模型）
3、準備測試集群環境
4、準備壓力測試工具或者編寫壓力測試腳本
5、明確性能指標并加監控
6、根據2設計的測試模型準備測試數據
7、測試執行
8、測試分析
本文依據以上步驟，模擬測試需求- 多實例多盤數據庫的性能對比測試，制定測試方案公布給大家，方便大家了解數據庫性能測試。
多實例多盤數據庫性能測試方案
一、測試目的
1、對比數據庫單實例、多實例的在不同硬件設備上的性能情況。
2、對比單機單實例和多實例的性能情況
3、驗證網絡帶寬是否成為flash產品發揮性能優勢的瓶頸。
4、驗證flash產品是否隨時間存在性能衰減的可能。
二、測試方法概述
測試基準工具：smart-slap（mysqlslap），Jmeter模擬若干客戶端、若干用戶執行指定的SQL語句，訪問數據庫。同時，通過監控工具監控系統負載、mysql數據庫的服務，全面了解數據庫系統以及硬件的負載情況。
測試模型
測試監控及結果統計
監控工具統計如下信息，分析性能瓶頸。
系統負載：
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，和響應時間分布。
（注意每一次測試命令中，涉及查詢條件的值隨機分布）
五、總結：
關于數據庫性能測試，只要掌握了壓力測試工具。最關鍵的還是設計出符合業務的測試模型，以及測試完成后的測試分析。通過實踐抽象出測試模型，進行自動化，則測試過程可以事半功倍。