在服務器上緩存數據是否會提高性能？

我有webservice（WCF）和MembershipProvider/RoleProvider來檢查憑據。在服務器上緩存數據是否會提高性能？

當服務調用 - 各種方法調用提供者獲取用戶，通過Id獲取登錄名，通過登錄名獲得Id等。最終結果 - 在Profiler中查看時 - 我可以看到很多聊天。

我可以很容易地將緩存合併到MembershipProvider和RoleProvider的緩存中，因此它會緩存用戶，並且不會每次都打到DB。

用戶列表不大。我認爲它不會超過100-200。

一方面 - 我知道SQL Server會緩存小表，並設計爲處理這些選擇。 OTOH - 我在探查器中看到它:)而Web服務器端的內存將被佔用。另外，Web服務器上的查找仍然需要完成（CPU /內存）。

我想我想聽聽你的經驗，我應該甚至擔心這個東西嗎？我放置標籤「戰略上」，所以希望DBA和開發人員都會給我一些輸入:)

來源

2011-08-19 katit

當然，避免往返於數據庫服務器的往返回報。不僅是內存緩存問題。運行一個查詢，甚至是一個簡單的查詢，是一個相當複雜的過程：

連接必須打開和驗證。它通過連接池進行攤銷，是真的，但即使是彙集連接，仍需要在開放時間爲sp_reset_connection進行一次額外往返。
請求必須被編寫併發送到服務器
需要爲請求分配一個任務，並且工作人員必須提取任務。在SQL Server中工作人員是非常寶貴的資源，因爲有so few of them。
SQL必須解析您的查詢。在非常好的情況下，它可以跳過解析，但仍需要對輸入文本進行散列，請參閱Dynamically created SQL vs Parameters in SQL Server
查詢必須執行，獲取的鎖定，內存中的頁面查找。鎖定是特別昂貴的，因爲它可能與其他操作衝突並且必須等待。使用snapshot isolation可以幫助某些（大）範圍。
結果必須封送回客戶端。
客戶端必須解析響應元數據。
客戶端必須處理響應。

本地內存查找將贏得大多數時間。即使是像memcached這樣的遠程緩存查找，也會贏得數據庫查詢，無論查詢多麼微不足道。那麼爲什麼不總是在本地緩存？由於CS：緩存一致性和失效中最嚴重的問題之一。這是一個問題，的方式比你認爲的現在更困難，不管你認爲它有多難;）。您可以看看SQL Server自己的主動緩存失效解決方案Query Notifications，它對於相當靜態的結果集非常適用。我自己有一個LINQ與查詢通知項目集成，LinqToCache。

來源

2011-08-20 05:13:36

爲什麼優化直到需要？即使是小型的SQL Server安裝也可以毫無困難地處理數千個請求。 ADO.Net連接池是有效的。爲什麼浪費時間在200個用戶應用程序上查詢少量查詢時，最好在其他地方花費時間？ –

@ ChrisM.-雖然SQL Server的*吞吐量會很好，但延遲通常非常高。對於大多數非平凡的查詢，您至少需要10ms。如果你瞄準100-200毫秒的頁面加載，這是非常重要的。 – JulianR

@ChrisM：我同意不成熟的優化是一切邪惡的根源，但這並不意味着簡單地解僱這個話題。有關擴展的重要性的討論，請參見[如何使用SQL Server的StackOverflow擴展]（http://www.brentozar.com/archive/2011/11/11/how-stackoverflow-scales-sql-server-video/）。 –

取決於。當您想要刪除或禁用用戶的帳戶並使更改立即生效時會發生什麼？

您需要確保對用戶帳戶的所有修改始終反映在所有Web服務器上的高速緩存中。但最終，避免網絡IO（這會降低你的實際速度）很可能對個人而言並不明顯，但每次擊中數據庫都會有所不同。

雖然機會不大，但不值得。

來源

2011-08-19 21:02:47

+1除最後一句外。看到我的答案爲什麼。 –

我已經看到，即使是經常訪問的小型表格，這種策略也付出了巨大代價。在我們的例子中，我們將數據分發到每個本地Web服務器上的Express實例，而Web應用程序將查詢其本地副本，而不是使用網絡資源等困擾主OLTP服務器。隨着您的應用程序的增長並添加更多Web服務器，採取這種多讀取活動並從讀取/寫入數據庫加載遠離更大。

這是一個定製的解決方案，所以我們可以決定每個表如何能得到陳舊，數據變化是否被推到主服務器需要立即分發到客戶端或可以等到下一個計劃分配。

來源

2011-08-19 21:21:54

我們有一個基於HTTP的服務 - 噸的請求，並且每個請求需要被驗證（90％非常小的請求，其餘相當大）。即使將數據庫放在同一臺計算機上（24 GB RAM，快速磁盤等），通過實現緩存（基於ConcurrentDictionary），我們可以將可伸縮性提高100％，因此可以使用同一臺計算機提供雙倍的請求。

對於更改用戶/登錄等立即生效我們實現了一個web服務（SOAP），它被用於這種東西，並保持高速緩存的「直寫的方式」。

因此總而言之，我們對緩存非常滿意。

來源

2011-08-19 21:22:04 Yahia

我已經建立了許多使用各種ASP.Net提供程序的大型網站。我已經將它們寫入了Azure表存儲，Oracle，LDAP服務器以及各種自定義後端。

我個人不會擔心一段時間的規模。數據庫是快速和可靠的。只要你開始緩存這些數據，你就會有很多問題需要擔心：

緩存失效。用戶被解僱，並通過帶外過程更新數據庫。你如何更新你的網絡服務器緩存？
錯誤。儘管緩存並不難，但您需要編寫的代碼越少越好。
安全。有可能會忽略的安全問題。
時間。處理客戶功能。這更重要。

優化如果/當你需要。在此之前，添加功能讓你的東西變得更好。

如果您擔心規模問題，請將用戶/角色表格放在與其餘數據不同的數據庫中。如果您開始超出該服務器，您可以輕鬆地將您的用戶數據遷移到更大的數據庫。

來源

2013-05-08 16:54:01

在服務器上緩存數據是否會提高性能？

回答

相關問題