ASP.NET OutputCacheAttribute太好了，不是真的吗？

Question

所以我一直在研究在ASP.NET应用程序中减轻数据库负载的有效方法，并且我遇到了System.Web.Mvc.OutputcCacheAttribute。我之前使用过基于System.Web.HttpRuntime.Cache的缓存，它似乎在功能上非常相似。 我已经对它进行了大量的研究，只要你有效地配置它，我所看到的一切都将它描述为缓存请求的某种银弹。我觉得很难相信。我知道一些有效的缓存真的需要（在一定程度上）是基于某些条件存储输出数据，但它仍然只是简单地添加属性并让你的应用程序神奇地表现得更好。

有没有人对在ASP.NET中使用输出缓存的好处/缺点有任何经验？如果是这样，使用这种方法进行缓存的痛点是什么？

Answer 1

通过交换内存延迟，

缓存可以创造奇迹。魔鬼在“有效地配置它”。

重要的是要自己确定应用程序中可接受的行为，例如，如果首页上的“前3个帖子”长达1分钟就可以了吗？如果“当前在线用户”列表最长可达30秒，这样可以吗？如果主页需要0.75秒加载，还是需要更快？您对这些问题的回答将决定应该或不应该缓存的内容。分析您的应用程序，以便了解真正的性能瓶颈在哪里，以及它们存在的原因，以便了解优化/缓存工作的重点

.Net应用程序中有许多形式的缓存。 OutputCache只是一种形式：

• 应用程序级缓存（由应用程序中的所有内容共享 - Application[Key]）
• 对象缓存（使用缓存失效回调自动管理 - Cache[Key]）
• 输出缓存（缓存生成的aspx页面/部件输出 - OutputCache属性）
• 按请求缓存（在单个请求期间缓存计算数据 - Context[key]）
• 会话缓存（缓存特定于用户会话的数据 - Session[key]）

它们都有其优点和缺点，设计良好的应用程序可能会使用大多数或所有这些形式的缓存。如果您想要OutputCache考虑一些要点，请参阅以下几点：

• 尝试缓存部分页面而不是整页，因为它们更有可能重复使用。使用UserControl之类的组件构建页面可以在这里提供帮助。
• 小心使用一组变化很大的参数，例如每个项目ID不同的QueryString参数，因为您最终会生成大量不经常使用的缓存副本，会消耗大量的记忆力很少。
• 请注意，OutputCache仅保存ASPX标记的生成输出。因此，它不会像动态页面中的其他缓存类型一样，根据用户输入更改表单。

Answer 2

根据我的经验，这个属性有一个非常明显且经常被遗忘的事情。

事实上，缓存输出的方法在缓存后甚至不会被执行。因此，如果操作背后的代码有一些副作用，它们将不会发生（例如，记录到数据库DB的事实，即使用访问该页面的事实。）

由于这个原因，我至少看到了很少的非常讨厌的错误。

简短的建议：稀疏地使用它并且101％确定团队中的每个开发人员都非常清楚它是如何工作的。