我已经阅读了一些关于此主题的内容，但我很好奇有哪些最佳方法可以优化使用ASP.NET缓存以及如何确定应该将哪些内容放入和不放入缓存。另外，有没有什么经验规则可以决定某些内容在缓存中应该保留多长时间？
ASP.NET缓存优化的一些方法是什么？
3
- Rob
2
你读过MSDN文章《编写高性能Web应用的10个技巧》吗？第4条“ASP.NET缓存API”应该为你提供一些很好的背景知识，以便为你找到解决方案。祝你一切顺利。 :-) - Gabriel Chung
@Timothy - 没错，我还没有看到那个问题，请将其输入为答案并获得积分。 - rjzii
5个回答
1
一些经验法则
- 每次考虑使用缓存时，要从缓存未命中的请求数比率角度思考。如果针对此项请求的缓存大部分时间都会未命中，则维护该缓存项的成本可能不值得其收益。
- 考虑查询成本与缓存检索成本之间的权衡（例如，在简单读取情况下，由于序列化成本，SQL Server通常比分布式缓存更快）
一些技巧
- 在将字符串放入缓存之前进行gzip压缩。这实际上扩展了缓存并减少了在分布式缓存情况下的网络流量
- 如果您担心缓存聚合数据（例如计数）的持续时间，请考虑具有非过期（或长寿）的缓存聚合数据，并在更改基础数据时主动更新它们。这是一种有争议的技术，您应该真正考虑请求/作废比率后再进行操作，但在某些情况下，收益可能是值得的（例如，根据实现细节，每个用户的SO声望可能是一个不错的选择，而未回答的SO问题数量可能是一个糟糕的选择）
- Jaysen Marais
1
暂时不要实现缓存。
在尝试了所有索引、查询调优、页面简化和其他更为常规的提高性能的方法之后再考虑缓存。如果在最后一步之前就启用缓存，你将很难找出性能瓶颈所在。
当然，如果在最终启用缓存时你已经正确地调整了后端，它将比今天启用缓存更长时间地发挥更好的作用。
- Jason Kester
1
假设其他所有内容都已经正确调整，或者这是一个你想要将数据保留在ViewState之外的情况。 - rjzii
0
关于性能调优和缓存，我听过的最好的一句话是这是一门艺术而非科学。很抱歉我不记得是谁说的，但重点在于影响应用程序性能的因素太多了，你需要针对每种情况进行评估，并对该情况进行深思熟虑的微调，直到达到预期的结果。
我意识到我没有提供任何具体细节，但我认为你实际上也无法提供。
不过，我会给出一个之前的例子。我曾经参与开发一个应用程序，该应用程序频繁调用Web服务来构建客户档案，例如：
- 获取客户
- 获取客户报价
- 获取客户报价明细
每个由Web服务返回的对象都有助于构建最终页面所需的更高级别的对象。起初，我们将所有对象收集到主对象中并进行缓存。然而，当事情不如我们所愿时，我们意识到单独缓存每个调用的对象会更有意义，这样它可以在客户看到下一页时被重复使用，例如：
- [缓存]客户
- [缓存]客户报价
- [缓存]客户报价明细
- 获取客户报价升级
- Nick Allen - Tungle139
0
很遗憾，没有预先设定的规则...但是为了给你一个常识，我会说你可以轻松缓存：
- 应用程序参数（国家列表、电话代码等）
- 任何其他应用程序非易失性数据（角色列表，即使可配置）
- 经常读取且不会经常更改的业务数据（或者如果不是100%准确也没关系）
你不应该缓存什么：
- 经常更改的易失性数据（通常是业务数据）
至于缓存持续时间，我倾向于根据数据类型和大小使用不同的持续时间。应用程序参数可以缓存数小时甚至数天。
对于某些业务数据，您可能希望具有较短的缓存持续时间（几分钟到1小时）
最后一件事是始终挑战您操作的数据量。请记住，最终用户不会同时阅读数千条记录。
希望这能给您一些指导。
- Julien Jacobs
0
很难概括这种事情。唯一的硬性规则是，除非你知道需要优化某些东西，否则不要浪费时间去优化它。然后，正确的行动方案将在很大程度上取决于您应用程序的细节。
话虽如此...我几乎总是会将全局应用程序参数缓存到一些易于使用的对象中。这当然更多是编程方便而不是优化。
我编写特定数据缓存代码的唯一一次是为一个与非常慢的会计数据库接口的应用程序，然后它只读取不经常更改的数据。所有写入都进入数据库。对于SQL Server，我从未遇到过内置的ASP.NET到SQL Server接口是方程式中的瓶颈。
- Bryan Parker
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接