搞搞就懂

快取機制主要就是用「記憶體空間」來換取「資料查詢時間」，並且潛藏著資料時效性問題，因此開發人員需在天秤兩端讓「效能」及「資料即時性」達到完美的平衡，才可以將快取效果發揮到極致；本文先針對快取共用模組進行設計，後續會在此基礎上實踐不同情境下快取的使用方式。

使用 CTE 的出發點應是增加 TSQL 可讀性，但是在濫用的情況下對於效能的衝擊是相當大，因此請在發生 DB 效能問題的時候，不仿也考慮一下 CTE 是否為效能瓶頸的重要關鍵。

面對大量且重要性低的 LOG 紀錄需求(如：統計功能使用量)，可以考慮套用非同步射後不理機制來節省 Web API 被占用的時間，把資源留給其他更重要的項目；文末並針對 SynchronizationContext 議題進行探討，由於在這種情境下會有 context 消失問題存在，因此需設定 ConfigureAwait(false) 來讓後續作業順利進行。

測試過程中發現若使用 ProfiledDbConnection 包裝原本 DB 連線後，預期的非同步效果就會消失，感覺似乎在每筆 DB 查詢後都立即 await 獲得資料，因此在上線時除了關閉 NanoProfiler 結果頁外，也要記得調整回系統原本的 DB 連線方式。

在 Web API 執行過程中可能需要一次對資料庫提出數個操作需求，當這些查詢彼此沒有順序相依性時，就可以善用非同步的機制讓所有查詢盡可能一次送出，而最終只需花費單一最長查詢所需要的時間即可獲得所有查詢的結果，對於效能的提升相當有幫助。

當面對回應緩慢的 Web API 時，當下最想了解的莫過於各項行為對於時間的消耗，此時我們可以透過 nanoprofile 幫我們記錄下這些資訊，特別是在操作 DB 所耗費的時間，更是不費吹灰之力的自動逐條詳列，並可重現當下呼叫 SP 所傳入的參數值，確實是調教效能的好幫手阿！

效能調教首先就是需要一個近乎真實狀態的可重現情境來做為衡量依據，本文透過 JMeter 靈活的腳本設計方式來針對單個負載測試情境進行介紹。