效能問題的最佳化模型(M01)

前言
一、效能問題的最佳化模型

二、效能調校的各項環結
1、正確的SQL組態-Default Setting(當瞭解各項設定意義)
2、硬體需求預估(封裝與分散)
3、商業Logic規則
4、資料Lock(資料特性)
5、正確(適當的)SQL指令
6、應用程式的開發(SQL Native Client)
7、資料庫設計
8、資料庫服務架構(Service Broker=非同步訊息佇列)

三、好的效能的基本要素
1、系統各個環節都擁有最好效能。
2、效能問題在開發中就要注意，尤其是資料庫設計，事後的修正會造成整個資料架構的異動
=>資料庫不應由前端應用程式碼直接存取資料表，而是透過View、Stored procedure、User define function來存取，以提高資料表擴充性。
=>程式開發時最好快速建立測試系統(prototype)，讓使用者在測試環境中修正開發中的問題。
3、開發流程中，做壓力測試時，應高過使用者的標準，因為無法預測尖峰與離峰時間，最好一直加壓到系統無法承受，試出系統的各項邊界資訊ex:多少使用者可同時上線、最大資料容量，最小記憶體需求等。並記錄各項資料供日後參考。
4、當資料庫資料量大且商業邏輯要執行很久時，盡量讓使用者有部份回應。
====================
效能調校的定義
「太慢了」、「這系統毀了」、「它不會工作了」=>可進行效能調校
「這系統毀了」、「它不會工作了」=>備援回復、提高系統可獲得性(HA high Availability)
一、一般觀測的效能問題的現象有:
1、系統回應時間過久
2、每秒所完成的系統輸出入低於預期
3、相同環境，目前完成的工作量<先前完成的工作量 4、系統資源(ex:CPU、記憶體、硬碟或網路等)長時間處於耗量的狀態 =>調校目標主要以使用者的期望為依歸
====================
建立效能基準線(Baseline)
1、昔日系統正常運作的數據
2、調校前系統的各項數據
3、使用者希望達到的目標

一般使用者可以接受系統的回應時間是3~5秒。
使用者的期望通常來自於:
1、工作需求
2、以往系統的使用經驗
3、一些效能數據值(benchmark)
4、其它使用者使用類似功能的經驗
====================
效能調校的步驟
1、發現問題Discover the problem
=>對於問題是否有簡明的描述
=>使用者基準線與期待在哪裡
2、探究問題Explore the conditions
3、提供可能的解決方案Track down possible approaches
=>最早開始的，最晚結束
4、執行最有可能的解決方案Execute the most likely approach
=>Spend time now to save time later
5、完成收尾工作Tie up loose ends
====================
定義瓶頸
原本整個系統可以流暢地執行，但系統中若有一個環節無法處理該需求量，導致整個系統執行效率被卡住，該點就是瓶頸。
瓶頸=需求到達的速率>處理量(Throughput)

逐步縮小範圍問題
階段1:廣泛監控資料庫環境
階段2:建立模型，驗證假設
階段3:縮小效能問題到特定資料庫範圍
階段4:縮小效能問題到特定資料庫物件並隔離問題
階段5:施行解決問題