坦白说，我也不能确认我是否能够提供一些基础的信息，因为MSDN库包含你需要了解的一切用法。以下是.NET Framework 1.1、2.0和3.0版本的链接。因此，我想我最好关注整个ASP.Net Web应用程序的缓存。
ASP.Net支持两种类型的缓存：数据缓存和页面缓存。数据缓存允许你保留正常在关联以外的数据，并在完成页面处理后为垃圾收集做好准备。页面缓存允许将页面输出保存在服务器中，然后从内存中恢复它们，而不是重新进行处理。两种缓存机制都提供使缓存无效的功能。
当一个数据元素在缓存以外时，你或者可以采用回调重新生成它，或者在需要它时查看它是否还在原处，然后再重新生成它。如果缓存无效，页面缓存会重新对页面进行处理。
有效利用缓存的诀窍在于理解它代表的权衡关系。缓存使用内存，而内存是一种相当有限的资源。如果内存运行缓慢，ASP.Net缓存会清扫缓存。幸运的是，在清扫过程中，你可以设置优先，保留一些项目。如果没有这些线索，清扫机会首先清除旧的和很少使用的项目。
因此，在缓存中存储许多大型对象或页面可能会产生负作用。如果对象或页面在缓存中保存的时间不够长，不足以抵消缓存中固有的管理费用，那么性能就会出现净下滑。
还要认识到，缓存并不常用的数据完全是浪费系统资源。此外，缓存经常需要使其无效的数据（以页面视图百分比，而不是每天的次数来测量）也是一种浪费。例如，缓存每小时显示三或四次，但每两分钟就需要重新生成的股票行情收录器就是对服务器内存的浪费。
ASP.Net缓存也在不断进化。在决定是否使用它时，确定你评估的是将在应用程序上运行的同一个版本的缓存。例如，.Net 1.1 Framework没有SQL Server缓存，但.Net 2.0和3.0有SQL Server缓存。确实，.Net 3.0中的缓存相当简单，它只有三种类型的失效（时间、文件改变和键改变）。
让SQL Server自动使缓存失效也相当有趣。在SQL Server 2000中，你需要定期检查数据库，仅查看是否有一个表发生了改变。SQL Server 2005探测缓存并告诉它失效，它也支持行级失效。老实说，虽然这似乎是一个非常好并且有用的特性，但它也建立了大量的厂商锁定。
你最好是使用键缓存让你的应用程序的应用层来处理缓存。虽然这样做可能不如行级改变的自动通知那样迅速有效，但你可以用一个精心设计的数据库来达到几乎相同的目的：用缓存中的对象来保留记录的主记录ID（如雇员表的记录ID），然后把数据库中那个主记录的失效层叠到其它相关的缓存项目（如那名雇员的薪水册数据）。虽然这样做可能要付出一定的努力，但你会获得回报，让应用程序保持厂商中立。
虽然缓存好像是提高性能的妙方，但你必须谨慎地使用它。如果对进行缓存的数据选择不当，就可能伤害到你的性能或浪费服务器资源，使得问题比以前更加恶化。衡量你的选项并执行一些负载测试看看缓存是否有用。
最好的方法可能是仿造应用程序的一个速成版本；一旦它模拟后端性能后（有意减速以复制处理时间），再把它放在一个现实的负载下，看看缓存能否提高性能。
安装和使用页面缓存相当方便，至少具有简单的失效（时间、文件）规则，但试用应用程序数据缓存和更加高级的页面失效功能可能需要预先做大量的工作才能生成现有的代码。应用缓存需要提前进行规划，而不能事后才追悔，认为它能提高性能。
发表回复