IIS6 ASP.NET 2.0 應用程序緩存 - 大量數據的數據存儲選項和性能

Question

在IIS6上的 ASP.NET 2.0 站點中，我想將鍵/值對存儲在應用程序緩存中。 每個 Key 始終是一個長度為 5 個字符的字符串，每個 Value 是一個長度為 15 - 250 個字符的字符串。

使用場景是每個網頁請求都會查詢一次緩存，如果存在密鑰，則使用值，否則查詢數據庫並根據某些應用程序邏輯向緩存添加新的密鑰/值或替換現有條目。

在這種情況下，我設想/要求緩存大小達到大約 1000 個條目，在該大小時它將變得穩定並且很少（如果有的話）如上所述進行更改。

在我只是“自己進行性能測試”之前，是否有人對大量緩存數據有任何經驗，以確定性能是否更可取：

(1) 使用包含SortedDictionary<string, string>的 1 個緩存 object 或

(2) 允許創建 1,000 個 Cache 對象並將 Cache 本身用作字典或

(3) 所討論的數據量無關緊要。 如果條目數增加到 10,000 或 100,000，在哪種情況下您的答案會改變？

非常感謝。

Answer 1

1000不是大數據量； 這樣可以正常工作，但是如果在請求之間共享此數據，您將需要考慮同步。 實際上，訪問Dictionary<string,string>的lock可能很好，但如果需要，您可以更細粒度。

然而，內置的 web 緩存 ( HttpContext.Cache ) 也會解決同樣的問題，並且內置了所有線程安全。

不要使用SortedDictionary<,>除非您關心數據是否已排序。 我不認為你這樣做。

隨着數字越來越大，我更傾向於考慮 redis / memcached 等存儲，將本地 memory 作為本地快捷方式。