请问你觉得生产静态页面一点意义都没有吗？

我知道你一直主张用MS自带的缓存功能。我想知道，你怎么看待静态页面和他两个。能介绍下什么情况下会选择哪个方式吗？

假如有100万个页面，甚至更多，每天，有5%的页面会浏览十次以上，有50%的页面只浏览一次。剩下45%根本没人看过。

这种情况你选择这么做？
另外我有个疑问，用缓存时，如果内存不够了怎么办？是用硬盘存放，还是释放缓存？

恳请SP1234百忙中给予解答。谢谢。其实关于静态页面还有很多问题，留待下次请教你吧。




---------------------------------------

我实际上曾经作为CMS项目经理开发过“静态页面”，因此我是根据自己“两方面都做过商品化项目”的实际经验来评估的。

---------------------------------------

成熟的缓存系统关键就是它会智能地丢弃缓存的内容，而这个“丢弃”的时机是经过千锤百炼，要比你在自己的代码中使用内存方式通常要更适合服务器内存实际情况。
---------------------------------------
至于功能，就更无法比拟了。

缓存系统的主要特征是提供了各种灵活的Dependecy，不但内存达到一定条件（默认是60%），时间达到一定条件（产生之后的时间、最后访问时间），还可以依赖于文件改变、数据库改变，甚至自己编写缓存依赖条件，这是关键。

关键是对于交互式网站还需要大量使用“片段缓存”。

我没有一棍子打死“静态页面”做法，对于很简单的无交互网站当然可以。我要强调的是如果你的handler仍然是asp.net的，网页链接还是 asp.net方式的，如果删除网站的asp.net系统之后静态页面就不能从网站上正常导航到了，那种“静态页面”网站相对来说你当初就不应该使用 asp.net这种过分高级的工具开发。
---------------------------------------
实际上，这正是说明为什么有很多公司使用asp.net原因。asp.net是动态网站生成工具，你越是发掘动态交互网站的能力时（例如用户自己选择 theme），你才越是需要asp.net。“100万个页面”其实可能只是从20个aspx中动态产生的。asp.net缓存是内置在动态交互网站上已 经成熟的技术，你不需要纠缠于是否需要把整个网站导出以及导出之后带来的一切“动态”问题，直接在asp.net程序本身的优化升级过程中轻松搞定，提高 性能的同时没有丧失任何动态特征，在网站性能升级过程中丝毫没有“成事不足败事有余”之感，何乐而不为。
---------------------------------------
使用asp.net的关键是会设置最恰当的“缓存依赖条件”。我看到很多人仅会设置Duration参数，这可能是“滥用缓存”或者“不用缓存”的原因。要恰好让依赖的数据改变时缓存立刻失效，而依赖的数据没有改变时要千方百计地优先使用缓存，才能提高网站性能。
---------------------------------------
如果明知道一个页面很少使用，首先是没有必要缓存。

其实，我从来不用页面缓存，我都是片段缓存的。当然我不反对页面缓存，而是对我来说用户控件才是编程核心，页面都是很简单的，几乎10秒钟创建一个页面，剩下的功夫就是把以前做好的用户控件添加其中并设置它们之间数据协调一致。

关于数据库表更新问题，可以参考有关页面缓存管理中的SqlDependency资料。

也可以简单一些。我在那个“如何看你的缓存是否生效”的帖子中写的例子里是根据cookie来刷新缓存，当然你可以改为返回数据表中的某个“时间戳”的 值。例如一个“用户订单”的界面（不是指订单细节，而是指订单的头部信息），你在数据库中可以为这个“订单”表增加一个“最后修改时间”字段以及增加一个 触发器来产生这个字段值，这样订单界面在用户录入细节内容时它的头部信息部分可以作为一个独立的ascx，当用户编辑订单细节时订单头部实际上并不重建控 件。你在订单界面上可以用代码输出订单头部用户控件的对象，你会发现它大多数时候是null，也就是说当编辑订单细节时订单头部控件“根本不存在”， asp.net只是从缓存中拿出html直接输出。既然根本没有重建用户控件，当然不会去读数据库。
---------------------------------------
一种情况是确实是1个小时也难得有一个访问，可能是根本无需缓存。这类页面即使不缓存，也没有什么损失。

另一种是你完全可以缓存较长时间，例如缓存1个小时。是不是缓存缓存时间越长就代表优先级越高？显然不是。如果内存不足，任何不常用的东西首先被从内存删 除，跟你设置的Duration无关。因此，如果你设置缓存1个小时，然后它被在千分之一秒内被删除了，即使这期间没有一个请求访问过缓存的页面，花费千 分之一秒时间代价也无所谓。如果你设置为缓存10秒钟，但是通常在10秒钟内不足够有一个请求访问它，这个代价才不值得缓存。我们可以看见，如果缓存不值 得，首先的考虑可以是加大缓存时间，例如从10秒钟变为30秒钟、1分钟、5分钟、20分钟、1小时。当很大的缓存时间还是觉得不值得，才根本取消缓存。 如果又希望避免重建控件内容，又害怕“不停的缓存、失效”，这其实是自相矛盾的。关键是：1：设置了缓存时间只是最低级的缓存策略，必须同时配合业务要求 来控制缓存及时失效；2:相信不论你如何设置缓存依赖条件，缓存系统都会优先根据服务器内存使用情况来自己决定是否提前清理缓存的对象，因此尽量使用缓 存并不会造成服务器内存实际的故障。
---------------------------------------
后它被在千分之一秒内被删除了-->然后它在1个小时后某个时间点被asp.net在千分之一秒内删除了
---------------------------------------
这其实根本不是缓存过期，而是网站更新，整个进程重新启动。什么时候网站必须更新？如果你生成了一堆静态页面，但是网站必须重新更新，此时那些静态页面能够幸免被重建的命运吗？如果能够幸免，也就无需重新更新网站程序。
---------------------------------------
我最头疼的就是很多人把asp.net的缓存机制说成是“定时保存”对象，这是一种很“坏”的歪曲。Duration时间是我们给缓存一个最低级、最基础 的约束，然后我们就必须给它一个业务需要的“适时失效”约束。把缓存理解成为在内存中以一段固定的时间占用内存，这是很偏的，造成了滥用缓存或者不用缓存 的结果。
---------------------------------------
sorry，我记忆中很难想起哪一个是不得不进行文件依赖的！除非逻辑上本来就是依赖这个文件，否则丝毫无需用文件依赖。
另外，文件依赖仅需要设置一个文件路径字符串而已，并不是错综复杂。真正造成错综复杂的，可能使在逻辑上根本无需文件依赖的时候一定要将许多其它数据改变 导成文件依赖这个结果上。这其实查找技术的问题。缓存还是很简单的，只是你找到的资料少，可能不像介绍GridView控件的资料那样地泛滥而已。
---------------------------------------
除了我的页面都是用户控件组合而成之外（至少我可以在一个页面上仅放一个用户控件，当然至今还不会使用masterpage），不使用页面缓存的理由还包括很重要的：UpdatePanel不支持。这很自然，整个页面缓存了，UpdatePanel的事件就无法触发。

但是片段缓存完全支持UpdatePanel。
---------------------------------------
我举了一个例子：
http://topic.csdn.net/u/20080428/16/3d1fe832-b328-49b4-9a54-d193e3e03a17.html

VaryByParam、VaryByControl等的例子网上有很多。

实际上，如果使用Page.LoadControl来动态加载用户控件，要知道PartialCachingControl这个对象（类）的编程。它的 CachePolicy属性可以调用缓存api，它的Dependency属性可以接受你自定义的Dependency。

网上也有一些自定义缓存依赖对象的文章，就是从CacheDependency类继承并写自己的控制代码。这些文章中文的可能不太多。

不过我写的那个例子其实已经很够用了，加入一些数据控制的代码来获得正在处理的ascx的对象的信息，就能达到大多数asp.net性能优化的要求。

---------------------------------------
注意一点，我在网上读过这样的文章，它把数据表保存到Session中，然后大谈在什么逻辑下用代码去从Session中删除数据表。它把这个叫做缓存！ 我所说的asp.net绝非这种编程，而是指asp.net自身（原生）的缓存。如果把数据表放到Cache中，当内存不足时缓存系统会自动删除它。因此 Session集合不是缓存，asp.net的数据缓存集合是指Cache集合而不是Session集合。asp.net进程重启也不是缓存刷新，整个进 程都重启了，缓存当然不见了，但是进程重启并不是缓存系统可以决定的事情。

---------------------------------------


---------------------------------------


---------------------------------------


---------------------------------------


---------------------------------------