缓存策略,输出缓存与数据缓存还是两者兼而有之？

我正在开发一个ASP.NET MVC项目,我已经开始考虑我的缓存策略了.我试图让我的框架尽可能开放用于缓存.

根据我在Scott Hanselman播客期间听到的内容,StackOverflow.com使用页面输出缓存并将内容拉链并将其放入RAM中.这听起来像是对用户范围的缓存非常有用,但对于像个性化页面这样的东西,你必须为每个用户缓存一个版本,并且可能很快失控.

所以,对于缓存策略.哪个应该使用,输出缓存,数据缓存还是组合？我的第一个想法是两者,但就缓存依赖性而言,它听起来有点复杂.

我们正在大规模(每天访问300万次)网站(新闻门户网站)进行API和输出缓存.该网站主要由匿名用户使用,但我们确实有经过身份验证的用户,我们只为他们缓存一个完整的网站,因为该网站的一些个性化部分,我必须承认我们绝对没有内存压力问题.

因此,我的建议是在API缓存中缓存所有内容,以便更快地进行输出缓存重建.

当然,请密切关注性能计数器中的缓存比值.您应该看到数量> 95%的缓存命中数.

要注意的另一件事是缓存失效,如果你有很多相关内容,这是一个大问题.例如,您可以缓存音乐内容,并且可以在几百页上显示和缓存有关一个专辑或歌曲的信息.如果该歌曲有任何变化,您必须使所有这些页面无效,这可能会有问题.

最重要的是,缓存是ASP.NET的最佳功能之一,它完美无缺,你可以依赖它.

过度激进的缓存要小心.虽然缓存是一种帮助提高性能的工具,但如果使用不当,实际上可能会使性能变差.

如果不了解有关项目的更多详细信息,我无法回答输出缓存或数据缓存是否会更好地为您服务.我可以帮助提供几个何时使用另一个的例子.

如果您有一个特定的数据集,您可以在许多不同的视图中使用这些数据集,那么最好使用数据缓存.如果您的数据提取操作相对于数据呈现非常常见且昂贵,则可以使用此方法.如果您有多个使用相同数据的视图,则可以节省数据提取时间.

如果您有一个使用非常特定数据集的视图并且视图的呈现很复杂并且经常请求此视图(例如,堆栈溢出的主页),那么您将从输出缓存中受益匪浅.

所以最后,它确实取决于您的需求,并且小心使用缓存不正确.