基准測試方法
在了解基本概念之後現在可以來具體討論下如何設計和執行基准測試但在討論如何設計好的基准測試之前先來看一下如何避免一些常見的錯誤這些錯誤可能導致測試結果無用或者不精確
使用真實數據的子集而不是全集例y 如應用需要處理幾百GB 的數據但測試只有GB 數據或者只使用當前數據進行測試卻希望模擬未來業務大幅度增長後的情況
使用錯誤的數據分布例如使用均勻分布的數據測試而系統的真實數據有很多熱點區域（隨機生成的測試數據通常無法模擬真實的數據分布）
使用不真實的分布參數例如假定所有用戶的個人信息（profile）都會被平均地讀取注
在多用戶場景中只做單用戶的測試
在單服務器上測試分布式應用
與真實用戶行為不匹配例如Web 頁面中的思考時間真實用戶在請求到一個頁面後會閱讀一段時間而不是不停頓地一個接一個點擊相關鏈接
反復執行同一個查詢真實的查詢是不盡相同的這可能會導致緩存命中率降低而反復執行同一個查詢在某種程度上會全部或者部分緩存結果
沒有檢查錯誤如果測試的結果無法得到合理的解釋比如一個本應該很慢的查詢突然變快了就應該檢查是否有錯誤產生否則可能只是測試了MySQL 檢測語法錯誤的速度了基准測試完成後一定要檢查一下錯誤日志這應當是基本的要求
忽略了系統預熱（warm up）的過程例如系統重啟後馬上進行測試有時候需要了解系統重啟後需要多長時間才能達到正常的性能容量要特別留意預熱的時長反過來說如果要想分析正常的性能需要注意若基准測試在重啟以後馬上啟動則緩存是冷的還沒有數據這時即使測試的壓力相同得到的結果也和緩存已經裝滿數據時是不同的
使用默認的服務器配置第 章將詳細地討論服務器的優化配置
測試時間太短基准測試需要持續一定的時間後面會繼續討論這個話題只有避免了上述錯誤才能走上改變測試質量的漫漫長路
如果其他條件相同就應努力使測試過程盡可能地接近真實應用的情況當然有時候和真實情況稍有些出入問題也不大例如實際應用服務器和數據庫服務器分別部署在不同的機器如果采用和實際部署完全相同的配置當然更真實但也會引入更多的變化因素比如加入了網絡的負載和速度等而在單一節點上運行測試相對要容易在某些情況下結果也可以接受那麼就可以在單一節點上進行測試當然這樣的選擇需要根據實際情況來分析是否合適
返回目錄高性能MySQL
編輯推薦
ASP NET開發培訓視頻教程
數據倉庫與數據挖掘培訓視頻教程
Oracle索引技術
From:http://tw.wingwit.com/Article/program/MySQL/201311/29740.html
