【问题标题】:ASP.NET OutputCacheAttribute too good to be true?ASP.NET OutputCacheAttribute 好得令人难以置信?
【发布时间】:2013-01-06 05:12:53
【问题描述】:
所以我一直在寻找有效的方法来减轻我的 ASP.NET 应用程序中数据库的负载,我遇到了System.Web.Mvc.OutputcCacheAttribute。我之前使用过基于System.Web.HttpRuntime.Cache 的缓存,它似乎在功能上几乎是等效的。
我已经对它进行了大量研究,只要你有效地配置它,我所看到的一切都将它描述为缓存请求的某种灵丹妙药。我觉得这很难相信。我知道,一些有效的缓存真正需要(在一定程度上)是根据特定条件存储输出数据,但是仅仅添加一个属性并让你的应用程序神奇地表现得更好似乎仍然太容易了。
有没有人对在 ASP.NET 中使用输出缓存的优点/缺点有任何经验?如果是这样,使用这种方法进行缓存的痛点是什么?
【问题讨论】:
标签:
asp.net
performance
caching
【解决方案1】:
缓存可以通过用延迟换取内存来创造奇迹。魔鬼在于“有效地配置它”。
重要的是自己确定应用程序中可接受的行为,例如,如果首页上的“前 3 个帖子”存在 1 分钟之久,是否可以?如果“当前用户在线”列表最多 30 秒,可以吗?如果主页需要 0.75 秒加载,是否可以,还是需要更快?您对这些问题的回答将决定什么应该或不应该被缓存。分析您的应用程序,以便您了解真正的性能瓶颈在哪里以及它们存在的原因,以便您知道将优化/缓存工作重点放在哪里
.Net 应用程序中有多种形式的缓存可用。 OutputCache 只是一种形式:
- 应用程序级缓存(由应用程序中的所有内容共享 -
Application[Key])
- 对象缓存(通过缓存失效回调自动管理 -
Cache[Key])
- 输出缓存(缓存生成的 aspx 页面/部分的输出 -
OutputCache 属性)
- 按请求缓存(在单个请求期间缓存计算的数据 -
Context[key])
- 会话缓存(缓存特定于用户会话的数据 -
Session[key])
它们各有优缺点,设计良好的应用程序可能会使用大部分或所有这些形式的缓存。如果您想对OutputCache 考虑一些要点,这里有一些:
- 尝试缓存页面的一部分而不是整个页面,因为它们更有可能被重用。使用
UserControl 之类的组件构建您的页面在这里会有所帮助。
- 谨慎使用一组变化很大的参数,例如每个项目 ID 不同的
QueryString 参数,因为您最终会生成大量不经常使用的缓存副本,从而消耗大量内存收益甚微。
- 请注意,
OutputCache 只是保存生成的 ASPX 标记输出。因此,它不会像根据用户输入更改表单的动态页面中的其他缓存类型一样工作。
【解决方案2】:
根据我的经验,关于这个属性有一件非常明显但经常被遗忘的事情。
事实上,输出被缓存的方法在被缓存后甚至不会被执行。因此,如果操作背后的代码有一些副作用,它们将不会发生(例如,将用户访问页面的事实记录到数据库 DB)。
因此,我至少看到了几个非常讨厌的错误。
简短的建议:少用它,并 101% 确保团队中的每个开发人员都非常了解它的工作原理。