當前位置:
首頁 > 最新 > SQL Server 性能測試指標分析

SQL Server 性能測試指標分析

你所負責的資料庫目前能扛得住多少並發?

將 「 扛得住 」 的指標細化一些:

1.假如10個並發查詢,500ms得出結果,非常好;

2.假如10000個並發查詢,500ms得出結果,非常好;1s得出結果也勉強;10s得出結果,也能忍受;30s返回(最長的返回時間),基本可以斷定系統吃力了;甚至有可能是頻繁超時(超過50%的查詢),這是肯定扛不住的節奏。

沒有一個恆定的指標可以拿出來做並發容量的測試標準。

我們能做的事情,就是從客戶端響應和伺服器性能指標,來推測當前系統配置能夠扛得住的並發。

當然在系統上線之前,如果我們能做好系統並發容量的控制,給出一個最大並發支持量,並在系統上線之後,對此並發量做監控,達到峰值之後,做好相應的擴容措施,是極好的。做好部署前的測試工作,得到 benchmark 有利於預估系統承載量。

有些系統在沒有前期測試並發容量的情況下就匆忙上線,想想真是有些後怕的。有可能就是一上線就掛,根本沒有用戶體驗可言(中讀-三聯周刊 app 那一次, 一時間大約幾萬人湧進去註冊,延遲得連 app 都打不開,更別說促銷返利)。大多數的系統都是這樣的,後期靠性能監控器排查並發問題。

他的主要方法還是查看 sql server performance management view 中的性能指標。所以他的措施還是停留在事後分析的階段,並沒有給出如何就在上線前鑒定系統並發量。

鑒定系統並發量的本質就是測試性能指標。CPU, Memory, Disk I/O 三大組件是資料庫系統著重考察的性能指標。任何的並發量都需要建立在這三者的動態平衡上,即任何一個組件的瓶頸都將帶給系統延遲。

比如 SSD 目前的隨機讀寫速度是, 以 Samsung 960pro 為例, 讀取速度達到 3500 MBps, 即 3.5 GB 每秒,而 Samsung 860pro , 順序讀寫的速度分別是 562.9 MB/S, 532.7 MB/s, 隨機讀寫的速度分別是353.5MB/s, 345.2MB/s. 當每秒請求的數據量超過 600MB 的時候,即使內存還有空閑,但依然會感受到延遲。

比如我們需要知道目前 sql server 中的並發量有多少,可以通過查看這個指標,來確定:

1 sys.dm_os_performance_counters 中 counter_name = "User Connections"

如果我們將指標放大一些,當然類似的還有 Logical Connections, Open Connection Count:

select * from sys.dm_os_performance_counters

where object_name like "%conn%" Collate Latin1_General_CI_AI

2 更加實時的收集用戶數的方法是,通過sys.dm_exec_sessions :

select db_name(eS.database_id) as the_database

,eS.is_user_process

,count(eS.session_id) as total_database_connections

from sys.dm_exec_sessions

order by 1,2

2. 除了使用 performance dynamic view 來抓取數據之外,還可以依靠windows perfmon.這大概是大家平時都會選用的windows 管理工具了。好處是實時性非常強,不足之處是處理日誌分析,比較頭疼。

假如我們需要從客戶端來評判,sql server 反應時間,那麼只需要記錄兩個維度和一個指標,即響應時間:

1. 測試時間

2. 當前並發量

3. 響應時間ms

隨著時間的推移,慢慢增加訪問量,監控平均(是否使用響應時間中位數)響應時間和最大響應時間的趨勢。

如果並發量臨界點是由於缺乏線程池造成,那麼就要手工維護連接線程池,即分配固定數量的線程,來相應前端的請求,以免造成一個請求一個線程,造成 SQL Server 內存的浪費。

一個相同配置的連接,就被看成是可以 pooling 的連接。open/close 可有效減少物理連接的打開/關閉次數。那麼一個打開的連接池中的連接,最多可以支持多少並發呢?

MSDN: Connections are added to the pool as needed, up to the maximum pool size specified(100 is the default).

如果不給 maximum pool size 指定一個具體的數字,那麼超過 100 個並發,就會有錯誤產生,因為連接池的連接不夠用了,或者有明顯的延遲,超過默認的15秒之後,就會報出異常。

而這一切對於開發者來說,都是黑盒,即是由 Ado.net 來自動化完成的。什麼時候分配連接,回收連接,給連接標上 invalid 屬性, 關閉連接池。可以對連接池的連接可用數量和正在使用連接數量做一個實時的監控,這樣就知道最大並發多少了。正在使用的連接,保留其使用,一定要不斷的與伺服器交互,並且處理數據。

以上是整個測試系統性能的主要方法,代碼部分有興趣的朋友可以留下郵箱,我們進一步交流。

--------------------------------

歡迎關注【有關SQL】,入群討論技術


喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 有關SQL 的精彩文章:

TAG:有關SQL |