測試何種指標
在開始執行甚至是在設計基准測試之前需要先明確測試的目標測試目標決定了選擇什麼樣的測試工具和技術以獲得精確而有意義的測試結果可以將測試目標細化為一系列的問題比如這種CPU 是否比另外一種要快？或新索引是否比當前索引性能更好？
有時候需要用不同的方法測試不同的指標比如針對延遲（latency）和吞吐量（throughput）就需要采用不同的測試方法
請考慮以下指標看看如何滿足測試的需求
吞吐量
吞吐量指的是單位時間內的事務處理數這一直是經典的數據庫應用測試指標一些標准的基准測試被廣泛地引用如TPCC（參考http://wwwtpcorg）而且很多數據庫廠商都努力爭取在這些測試中取得好成績這類基准測試主要針對在線事務處理（OLTP）的吞吐量非常適用於多用戶的交互式應用常用的測試單位是每秒事務數（TPS）有些也采用每分鐘事務數（TPM）
響應時間或者延遲
這個指標用於測試任務所需的整體時間根據具體的應用測試的時間單位可能是微秒毫秒秒或者分鐘根據不同的時間單位可以計算出平均響應時間最小響應時間最大響應時間和所占百分比最大響應時間通常意義不大因為測試時間越長最大響應時間也可能越大而且其結果通常不可重復每次測試都可能得到不同的最大響應時間因此通常可以使用百分比響應時間（percentile responsetime）來替代最大響應時間例如如果% 的響應時間都是 毫秒則表示任務在% 的時間段內都可以在 毫秒之內完成
使用圖表有助於理解測試結果可以將測試結果繪制成折線圖（比如平均值折線或者% 百分比折線）或者散點圖直觀地表現數據結果集的分布情況通過這些圖可以發現長時間測試的趨勢本章後面將更詳細地討論這一點
並發性
並發性是一個非常重要又經常被誤解和誤用的指標例如它經常被表示成多少用戶在同一時間浏覽一個Web 站點經常使用的指標是有多少個會話注然而HTTP協議是無狀態的大多數用戶只是簡單地讀取浏覽器上顯示的信息這並不等同於Web 服務器的並發性而且Web 服務器的並發性也不等同於數據庫的並發性而僅僅只表示會話存儲機制可以處理多少數據的能力Web 服務器的並發性更准確的度量指標應該是在任意時間有多少同時發生的並發請求
在應用的不同環節都可以測量相應的並發性Web 服務器的高並發一般也會導致數據庫的高並發但服務器采用的語言和工具集對此都會有影響注意不要將創建數據庫連接和並發性搞混淆一個設計良好的應用同時可以打開成百上千個MySQL 數據庫服務器連接但可能同時只有少數連接在執行查詢所以說一個Web 站點同時有 個用戶訪問卻可能只有 ～ 個並發請求到MySQL 數據庫
換句話說並發性基准測試需要關注的是正在工作中的並發操作或者是同時工作中的線程數或者連接數當並發性增加時需要測量吞吐量是否下降響應時間是否變長如果是這樣應用可能就無法處理峰值壓力
並發性的測量完全不同於響應時間和吞吐量它不像是一個結果而更像是設置基准測試的一種屬性並發性測試通常不是為了測試應用能達到的並發度而是為了測試應用在不同並發下的性能當然數據庫的並發性還是需要測量的可以通過sysbench 指定 或者 個線程的測試然後在測試期間記錄MySQL 數據庫的Threads_running 狀態值在第 章將討論這個指標對容量規劃的影響
可擴展性
在系統的業務壓力可能發生變化的情況下測試可擴展性就非常必要了第 章將更進一步討論可擴展性的話題簡單地說可擴展性指的是給系統增加一倍的工作在理想情況下就能獲得兩倍的結果（即吞吐量增加一倍）或者說給系統增加一倍的資源（比如兩倍的CPU 數）就可以獲得兩倍的吞吐量當然同時性能（響應時間）也必須在可以接受的范圍內大多數系統是無法做到如此理想的線性擴展的隨著壓力的變化吞吐量和性能都可能越來越差
可擴展性指標對於容量規范非常有用它可以提供其他測試無法提供的信息來幫助發現應用的瓶頸比如如果系統是基於單個用戶的響應時間測試（這是一個很糟糕的測試策略）設計的雖然測試的結果很好但當並發度增加時系統的性能有可能變得非常糟糕而一個基於不斷增加用戶連接的情況下的響應時間測試則可以發現這個問題
一些任務比如從細粒度數據創建匯總表的批量工作需要的是周期性的快速響應時間當然也可以測試這些任務純粹的響應時間但要注意考慮這些任務之間的相互影響批量工作可能導致相互之間有影響的查詢性能變差反之亦然
歸根結底應該測試那些對用戶來說最重要的指標因此應該盡可能地去收集一些需求比如什麼樣的響應時間是可以接受的期待多少的並發性等等然後基於這些需求來設計基准測試避免目光短淺地只關注部分指標而忽略其他指標
返回目錄高性能MySQL
編輯推薦
ASP NET開發培訓視頻教程
數據倉庫與數據挖掘培訓視頻教程
Oracle索引技術
From:http://tw.wingwit.com/Article/program/MySQL/201311/29741.html
