緩存LINQ to SQL DataContext

我們正在爲多租戶Web應用程序進行一些性能優化。目前，LinqToSql數據上下文是在每個Web請求開始時創建的。上下文對於Web請求具有一定的生命週期，並且使用Castle Windsor將其注入到需要它的任何對象的構造器中。緩存LINQ to SQL DataContext

我們曾想過在會話緩存中緩存上下文（以及一組對象），以便爲後續Web請求優化安裝成本。這是個好主意嗎？需要考慮哪些問題？

2010-07-30 Rob

您是否檢查過通過datacontext運行的每個查詢以確保最小化數據庫IO的消耗？您是否檢查了datacontext的調用者以確保重複提取相同的數據不會發生？ – 2010-07-30 18:26:04

@David：調整在探查器中顯示爲熱點的查詢。我們的存儲庫實現可防止反覆提取。 – Rob 2010-07-31 00:22:49

一個壞主意IMO。最大的問題是併發性。由於使用連接池，只要您將數據上下文用作數據的管道，而不是數據存儲桶本身，成本就沒有那麼多。

緩存數據;丟棄數據上下文。

試圖保留數據上下文此外不擴展到多個服務器，或支持除進程外的任何緩存實現。

你有沒有測量安裝費用，以便你知道這是否值得考慮？我真的不相信那是你的瓶頸。

2010-07-30 05:41:22

我們已經衡量。這不是創建直流問題，而是附加的數據。我們最初的想法是沿着你的路線，如果它是一個綠地開發的場景，我們肯定會重新加入。在重構上下文之前，我們想要了解如果我們只在短時間內保持dc完好無誤，實際上會出現什麼問題。 – Rob 2010-07-30 05:45:22

@Rob - 你不應該*在你的數據上下文中需要*數據。它並不意味着*被用作數據存儲（甚至包括*身份管理器）。就我個人而言，我會將這些數據移出數據上下文;使用數據上下文來**獲取**，但將其緩存在外部。 – 2010-07-30 05:55:28

@Mark - 同意。在綠地方案中，我們將如何處理這個問題。現有的存儲庫是這樣編寫的，以便他們假定實體在變更集中，所以我們必須從緩存中補充上下文。當然不是不可能的，這很可能就是我們要做的，但我們想在開發時間有限之前理解所有問題。 – Rob 2010-07-30 06:02:30

回答