我维护了几个没有任何动态数据的客户端站点,一切都是带有 c# 的静态 asp.net。
将整个页面缓存一段时间(例如一周)是否有任何陷阱?
Kibbee,我们在网站上使用了几个控件(广告旋转器,一些 ajax 扩展)。它们可能完全用 html 编写,但为了方便起见,我只是坚持使用我们用于其他所有站点的内容。
当您想要更新该数据时,长缓存时间的唯一重大缺陷会发生。为了安全起见,您必须假设新版本最多需要一周的时间才能可用。诸如 ISP 级代理服务器之类的中间主机通常会积极缓存,因此会发生这种延迟。
如果要缓存大文件,我会考虑确保您的内容引擎支持 If-Modified-Since。
对于较小的文件(页面内容、CSS、图像等),其中减少往返次数是关键,具有较长的有效期(一年?)并在内容更改时更改 URL 是最好的。这使您可以控制用户代理何时获取新内容。
雅虎!发表了一篇关于减少 HTTP 请求和浏览器缓存使用的两部分文章。我不会在这里重复这一切,但这些都是很好的读物,可以指导你做什么。
我的感觉是选择一个足够高的时间段来覆盖大多数用户的单个会话,但又要足够低,以免在您希望更新内容时造成太多不便。如果您的所有内容都有 Last-Modified,请务必支持 If-Modified-Since。
最后,如果您的内容完全可以缓存并且您现在需要推出新内容,那么您始终可以使用新的 URL。如果您希望发布到最新版本的永久链接,这个最终的可缓存内容 URL 可以位于固定的HTTP 302 重定向URL 之后。
在我正在进行的一个项目中,我们遇到了类似的问题。有些数据几乎是静态的,但可以更改。
我最终做的是将数据保存到本地文件,然后监视它的变化。除非我们删除文件,否则永远不会访问数据库服务器,在这种情况下,它会飞到数据库并重新生成数据文件。
因此,我们在加载/保存时基本上有一点磁盘 IO,除非必要,否则没有到数据库服务器的流量,我们仍然可以控制它(我们可以手动删除或编写脚本等)。
我还应该补充一点,如果你想减少磁盘 IO(在我们的例子中我们真的不需要),你可以将它与实际的 Web 服务器缓存模型联系起来。
这可能是完全错误的做法,但它似乎对我们很有效:)
如果它是静态的,为什么还要费心缓存呢?让 IIS 担心它。
当您说您没有数据时,您甚至如何使用asp.net或c#。与纯 HTML 相比,它为您提供了哪些功能?此外,如果您确实计划缓存,最好缓存到文件中,然后在发出请求时将文件流出。操作系统会负责将文件保存在内存中,这样您就不必一直从磁盘上读取它。
如果你想这样做,你可能想要建立一个缓存更新机制,只是为了确保你可以在需要进行代码更新时清除缓存。除此之外,没有任何我能想到的问题。
如果它是静态的,您最好生成一次页面,然后直接提供生成的静态 HTML 文件。