在决定何时以及如何缓存时，我们会考虑哪些问题，流程和问题。总是不赢吗？

前提是我们坚持使用经过优化的代码库。

解决方案

我会根据网站/应用程序的每个功能来决定每个功能：

• 应该缓存吗？
• 应该将其缓存多长时间？
• 什么时候应该清除缓存？

我个人反对缓存整个页面，而倾向于缓存网站/应用程序的各个部分。

我们使用什么语言？使用ASP，我们可以非常轻松地进行缓存，只需在方法上添加一些属性标签，然后根据时间来缓存值。

如果要对缓存进行更多控制，则可以使用一些流行的系统(例如MemCached)，并可以按时间或者按事件进行控制。

首先，如果按照我们所说的那样对代码进行了优化，则只有在网站处理大量请求时，我们才会看到显着的性能优势。

但是，从RAM中拉取资源比从磁盘中拉取资源更快，因此，如果有适当的缓存策略，则Web服务器将能够处理更多请求。

至于知道何时需要缓存，请考虑一下即使是低端的现代Web服务器也可以每秒处理数百个请求，因此，除非我们期望有可观的流量，否则缓存可能只是我们可以跳过的事情。

另外，如果我们要从数据库中提取内容(例如，StackOverflow可能会这样做)，缓存将非常有用，因为数据库操作相对昂贵，并且在大容量情况下可能成为巨大的瓶颈。

对于不适合缓存或者缓存变得困难的情况，如果我们尝试缓存一个动态页面(例如，显示当前日期和时间)，除非我们看到一个动态的页面，否则我们将不断看到一个旧的日期/时间。与缓存策略息息相关。所以这是需要考虑的事情。

例如，雅虎(Yahoo)对其JavaScript进行"版本化"，因此浏览器会下载代码1.2.3.js，并在出现新版本时会引用该版本。通过这样做，他们可以使他们的Javascript代码在非常长的时间内可缓存。

至于一般性答案，我认为这取决于数据以及更改频率。例如，图像不会经常更改，但是html页面会更改。 "关于我们"页面不会经常更改，但新闻部分会更改。

我最近一直在与DotNetNuke一起使用Web应用程序，每次实现缓存解决方案时，我都会考虑很多因素。

• 所有用户都需要查看缓存的内容吗？
• 每一点内容更改的频率是多少？
• 我可以缓存整个页面吗？
• 我需要手动清除缓存吗？
• 我可以对整个站点使用一种缓存机制，还是需要多种解决方案？
• 如果信息过时了会产生什么影响？

我们可以按时间缓存。这对于快速变化的数据很有用。我们可以将时间设置为30秒或者1分钟。当然，这需要一些流量。我们拥有的流量越多，时间就越多，因为如果我们每小时有1次访问，则此访问将被填充到缓存中而不使用它。

我们可以按事件进行缓存...如果数据发生更改，则可以更新缓存...如果需要非常快速地为用户提供准确的数据，这将非常有用。

我们可以缓存不会改变的静态内容。如果我们每天的前十名每天都刷新，那么我们可以将所有内容存储在缓存中并每天进行更新。

如果可用，请注意整个对象的内存缓存。在ASPNET中，这是一项内置功能，我们可以在其中将业务逻辑对象植入IIS应用程序中，然后从那里访问它们。

这意味着我们可以将生成页面所需的所有内容存储在内存中(持久写入数据库)并生成没有任何数据库IO的页面。

我们仍然需要使用页面构建逻辑来生成页面，但是可以节省大量时间来获取数据。

其他技术涉及本地化输出缓存，我们可以在发送前捕获输出并将其保存到文件中。这对于静态部分(例如某些页面上的导航或者文本正文)非常有用，并在需要时将其包括在内。大多数实现会在发生写操作时或者一定时间后清除缓存的对象。

然后是最不"准确"的：整个页面缓存。它是性能最高的，但是除非我们有非常简单的页面，否则它几乎没有用。

什么样的缓存？服务器端缓存？客户端缓存？

客户端缓存对于某些事情是不费吹灰之力的，例如静态HTML，SWF和图像。找出资产可能多久更改一次，并根据需要设置" Expires"标头。 (2天？2周？2个月？)

根据定义，动态页面更难缓存。已经进行了一些探索，以使用Javascript缓存某些块(如果JS不可用，则降级为IFrame。)但是，将其改造成现有站点可能会有些困难。

数据库和应用程序级缓存可能会或者可能不会起作用，具体取决于情况。这实际上取决于瓶颈所在。弄清楚应用程序在页面渲染上花费最多时间的地方可能是优先事项1，然后我们可以开始查看缓存的位置和方式。