一、背景

近期在進行資源調度管理平臺的重構工作,其中的Resource/Property數據庫設計,在沒有更加優化的方案前,打算沿用當前平臺的數據庫結構；這就需要對當前平臺的數據庫結構進行剖析研究,并對其性能進行測試與分析,得出的數據結果作為后續設計和優化的參考.

二、測試方法

1、測試工具：mysqlslap,mysqlslap是MySQL5.1.4之后自帶的benchmark基準測試工具,該工具可以模擬多個客戶端同時并發的向服務器發出查詢更新,給出了性能測試數據而且提供了多種引擎的性能比較.官方介紹：http://dev.mysql.com/doc/refman/5.6/en/mysqlslap.html,

使用方法：http://my.oschina.net/moooofly/blog/152547

2、測試流程：建立測試數據庫database和待測試的表tables → 根據table的結構,利用腳本生成一定數量的有效隨機數據 → 利用mysqlslap對相應query語句進行測試 → 結果數據的分析.

3、關鍵語句：考慮到資源平臺的實際應用情況,通過資源屬性查詢資源的操作為主要操作,且這類操作的耗時占總操作耗時的比例為最大,故對應這類操作的查詢語句為關鍵語句,對整個數據庫性能影響很大,我們可以通過測試這個關鍵語句得出的結果來評估整個數據庫的性能.

三、測試過程

1、建表：

通過屬性查詢資源需要兩張表：設備表device和設備屬性對應表deviceattr.device表對應資源,記錄資源的基本信息,如name,type,group,creator等等；deviceattr表對應資源和屬性的關系,記錄每個資源的每個屬性和屬性值；它們的結構如下所示：

通過多個屬性組合查詢deviceattr表,獲得相應的id ,id即是滿足條件的設備id,進而能直接在device表中查詢得到其基本屬性.

本次測試的關鍵語句即是從deviceattr表中組合查詢出滿足條件的id,故本測試只需要用到deviceattr一張表.

2、生成隨機數據并插入相應的表中：

這里編寫了幾個生成隨機數據的sql函數rand_name(),rand_value(),rand_num(),rand_creator(),并編寫了存儲過程insert_devattr,用來將一定量數據批量插入deviceattr表中.

然后將整個建表和存儲數據的過程寫進一個sql腳本中,并在mysql中運行這個腳本,待測試的表和數據就建立好了.(sql腳本在附錄)如下圖所示,生成的deviceattr隨機數據有4020條：

3、利用mysqlslap進行測試：

整個數據庫的關鍵操作為通過屬性查詢資源,該操作的關鍵sql語句就是:

select id from deviceattr where [ n attr ] group by id；

例：查詢擁有attr10或者attr20屬性的所有資源的id為：

select id from deviceattr where name = ‘attr10’ or name = ‘attr20’ group by id;

在建立好待測數據庫后,就可以利用mysqlslap進行測試,mysqlslap命令如下所示：

shell < mysqlslap --create-schema='test1' --query="select id from deviceattr where name='attr10' or name='attr20' group by id;" -c 50 -i 100

以上語句表示：使用test1數據庫,使用query所指定的語句,測試50個并發查詢,每一個查詢100次.

該語句的測試結果如下圖所示：

結果中可以看到執行語句的平均耗時,最大耗時和最小耗時,并發線程數等等.

四、結果分析

在不同數據容量,不同并發數,不同查詢屬性數的條件下進行多次測試并取平均值,所得到的數據分以下幾種情況進行分析：

1、在deviceattr表數據容量為4000條,并發數分別為1、5、10、20、40、80,查詢屬性數分別為2、3、4、5、6的情況下,查詢語句的耗時：

從上表可以看出,在查詢屬性數相同條件下,并發數增長一倍,耗時也基本增加一倍；在40并發數以下時,查詢耗時不超過100毫秒；在10并發左右的實際應用情況下,耗時在40毫秒左右；性能基本滿足新資源平臺的要求.

2、在10并發,deviceattr表容量分別為3000、4000、8000條,查詢屬性數從2至6的情況下,查詢語句的耗時：

從上表可以看出,在并發數一定的情況下,隨著語句中查詢屬性數的增多,耗時線性增加,這種線性關系數據容量無關.

3、在10并發,查詢屬性數為5,不同數據容量的情況下,查詢語句的耗時：

從上表可以看出,在其他條件一定的情況下,隨著數據容量的增長,耗時呈線性增長,在貼近實際條件的情況下(4000左右數據容量,10左右并發數,5左右查詢屬性),耗時為25毫秒,滿足新資源管理平臺的需求.

附錄：

生成測試數據的sql腳本：

use test1