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

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

假如有100万个页面，甚至更多，每天，有5%的页面会浏览十次以上，有50%的页面只浏览一次。剩下45%根本没人看过。这种情况你选择这么做？
另外我有个疑问，用缓存时，如果内存不够了怎么办？是用硬盘存放，还是释放缓存？

静态页面众所周知是以空间换时间. 当然这也是一个代价. 缓存功能很有效的降低网络的耗损,其他客户机在访问该网站的时候也会通过局域网内的缓存获取数据降低了服务端本身的压力.

静态页面除了以空间换时间，还有一定的IO损耗，并发量特别大的情况下完全采用静态页面也不是好的解决方法，例如你所提到的假如有100万个页面，甚至更多，每天，有5%的页面会浏览十次以上，有50%的页面只浏览一次。剩下45%根本没人看过。要我选择的话，在保证这些页面基本不怎么变动的话，我会将这5%的页面在程序初始的加入缓存，将50%的页面在第一次读取的时候加入缓存，剩下的作为静态页面储存。

（1）从安全角度出发，静态页面是安全的。
（2）正如刚才所说，在定期限内效率较态页面高，但假如有100万个页面，甚至更多，每天，有5%的页面会浏览十次以上，有50%的页面只浏览一次。剩下45%根本没人看过。 应该综合权衡一下，适当的静态化5%的页面，可以考虑用MS自带缓存；那50%的页面如果是并发访问，就得交给数据库服务器完成，建立索引，用户查询时动态的生成，oracle这方面比较棒。
（3）实际使用中，效率和安全稳定第一位。 

我觉得静态页面只适合于访问量大,并且静态页面数量小的情况.....
当一个文件夹下面有几千个静态文件的时候,效率呈级数下降.....
所谓容易被搜索引擎检索到,动态页面做成伪静态页面也可以的.
都存到数据库里,用户访问的时候生成静态页,访问静态页的时候通过脚本更新最后访问时间.
然后用WINDOWS服务来决定哪些访问量小的页面要删除...

至于功能，就更无法比拟了。
缓存系统的主要特征是提供了各种灵活的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参数，这可能是“滥用缓存”或者“不用缓存”的原因。要恰好让依赖的数据改变时缓存立刻失效，而依赖的数据没有改变时要千方百计地优先使用缓存，才能提高网站性能。

其实我很少使用页面缓存，我宁可用静态页面来代替，主要是因为我对缓存依赖没有掌握。至于数据片段缓存这个很简单，而且代码也比较通用。以前一直在用。

我在想，一个页面可能依赖几个表（数据库），一个表可能被多个页面依赖。也可以说成是多对多的关系。如何让这些改变能立刻生效，需要深入研究才能搞清楚。我目前对这个还是比较模糊。没有成功实现。所以我一直用静态页面的方式。数据改变了，我重新生成（不管是立刻，还是访问时再重新生成，都差不多）


但是显然用缓存依赖，我也觉得是很好的方案。这点我承认。我也会好好去研究一下。刚才你提到，对于不常访问的的页面，让他缓存失效，但是我举的例子里有50%页面可能每天访问一次，这样你要不停的缓存、失效。从逻辑上说，也比较走弯路。不如静态页面，一直放那里好。