MySQL基準測試

1、是什麼？

基準測試是針對系統設計的一種壓力測試

目標是爲了掌握系統的行爲

 

2、爲何？

基準測試是惟一方便有效的、能夠學習系統在給定的工做負載下會發生什麼的方法。

基準測試中的壓力不是來自真實，相對真實壓力來講比較簡單

基準測試一般要求儘量快地完成，因此常常給系統形成過大壓力

使用基準測試進行容量規劃不能只根據測試結果作簡單的推斷，咱們只能進行大概的測試，來肯定系統大體的餘量有多少。

 

3、基準測試的策略

基準測試有兩種策略：

一、集成式基準測試，針對整個系統的總體測試，應用的場景：須要儘量的體現應用的總體性能

二、單組件式基準測試，單獨測試MySQL，應用的場景：在項目的初期

 

4、測試指標

一、吞吐量

　　單位時間內的事務處理數

　　這類基準測試主要針對在線事務處理（OLTP）的吞吐量，很是適用於多用戶的交互式應用

　　測試單位是每秒事務數（TPS），有些也採用每分事務數（TPM）

二、響應時間或延遲

　　任務所需的總體時間

　　根據不一樣的時間單位能夠計算出平均響應時間、最小響應時間、最大響應時間和所佔百分比

　　最大響應時間一般意義不大，可使用百分比響應時間來替代，好比95%的響應時間都是5毫秒，則表示任務在95%的時間段內均可以5毫秒完成

三、併發性

　　Web服務器的併發性的度量指標是在任意時間有多少同時發生的併發請求。

　　併發性基準測試須要關注的是正在工做中的併發操做，或者是同時工做中的線程數或者鏈接數。

　　併發性測試一般不是爲了測試應用能達到的併發度，而是爲了測試應用在不一樣併發下的性能（併發增長時，測量吞吐量是否降低，響應時間是否延長）

四、可擴展性

　　給系統增長一倍的工做，在理想狀況下就能得到兩倍的結果（即吞吐量增長一倍），或者說給系統一倍的資源（好比兩倍的CPU數），就能夠得到兩倍的吞吐量

　　可擴展性指標對於容量規範很是有用，它能夠提供其餘測試沒法提供的信息，發現應用的瓶頸。

根據指標去制定需求（好比什麼樣的響應時間能夠接受、期待多少的併發性），而後基於這些需求來設計基準測試

 

5、基準測試方法

測試前先避免如下的常見問題：

一、使用真實數據的子集而不是全集

二、使用錯誤的數據分佈

三、使用不真實的分佈參數

四、在多用戶場景中，只作單用戶的測試

五、在單服務器上測試分佈式應用

六、與真實用戶行爲不匹配

七、反覆執行同一個查詢

八、沒有檢查錯誤，基準測試完成後，必定要檢查一下錯誤日誌

九、忽略了系統預熱的過程，須要瞭解系統重啓後須要多長時間才能達到正常的性能容量

十、使用默認的服務器配置

十一、測試時間過短

 

設計和規劃基準測試