IIS6 ASP.NET 2.0应用程序缓存 – 大量数据的数据存储选项和性能

在IIS6上的ASP.NET 2.0站点中，我想在应用程序缓存中存储键/值对。每个Key将始终是一个长度为5个字符的字符串，每个值为15到250个字符长度的字符串。

使用场景是每个网页请求将查询一次Cache，如果Key存在则使用Value，否则查询数据库并向Cache添加新的Key / Value或根据某些应用程序逻辑替换现有条目。

在这种情况下，我设想/要求高速缓存大小达到大约1000个条目，其大小将变得稳定并且很少（如果有的话）如上所述地改变。

在我“自己进行性能测试”之前，任何人都有大量缓存数据的经验，以确定Performance是否更适合：

（1）使用包含SortedDictionary或1的1个Cache对象

（2）允许创建1,000个Cache对象并使用Cache本身作为字典或

（3）对于有问题的数据量无关紧要。如果条目数增加到10,000或100,000，您的答案会在哪种情况下发生变化？

非常感谢。

1000不是大量数据; 这将工作正常，但如果请求之间共享此数据，您将需要考虑同步。实际上，访问Dictionary的lock可能没什么问题，但如果需要的话可以更精细。

但是，内置的Web缓存（ HttpContext.Cache ）也会遇到同样的问题，并且内置了所有的线程安全性。

除非您关心数据是否已排序SortedDictionary<,>否则请勿使用SortedDictionary<,> 。我不认为你这样做。

随着数字越来越大，我更倾向于考虑像redis / memcached这样的商店，将本地内存作为本地快捷方式。