文章回顾：
1： 秋色园QBlog技术原理解析：开篇：整体认识(一) --介绍整体文件夹和文件的作用
2： 秋色园QBlog技术原理解析：认识整站处理流程(二) --介绍秋色园业务处理流程
3： 秋色园QBlog技术原理解析：UrlRewrite之无后缀URL原理(三) --介绍如何实现无后缀URL
4： 秋色园QBlog技术原理解析：UrlRewrite之URL重定向体系(四) --介绍URL如何定位到处理程序
5： 秋色园QBlog技术原理解析：Module之页面基类设计(五) --介绍创建基类和自定义生命周期
6： 秋色园QBlog技术原理解析：Module之页面基类-生命周期流程(六) --介绍基类生命周期内部业务
7： 秋色园QBlog技术原理解析：Module之基类生命周期-页面加载(七) --介绍界面html加载原理
8： 秋色园QBlog技术原理解析：Web之页面处理-内容填充(八) --介绍html的内容是如何填充
9： 秋色园QBlog技术原理解析：独创的多语言翻译机制(九) --介绍html多语言翻译原理
10：秋色园QBlog技术原理解析：页面内容填充及多语言翻译流程演示示例(十) --总结演示示例代码
11：秋色园QBlog技术原理解析：页面Post提交机制(十一) --介绍如果Post提交数据
12：秋色园QBlog技术原理解析：性能优化篇：字节与缓存与并发(十二) --介绍性能优化：字节，并发及缓存
13：秋色园QBlog技术原理解析：性能优化篇：全局的SQL语句优化(十三) --介绍全局掌握SQL，进行针对性优化
附章：
1：秋色园QBlog技术原理解析：博客一键安装工具技术实现[附源码下载] --开源秋色园安装工具原理
PS：秋色园QBlog 下载地址：http://www.cyqdata.com/download/article-detail-427
上两节小回顾：
在上两节中，介绍了 秋色园QBlog 在性能优化方面所做的一些工作：
比如：减少字节输出大小、写并发控制、缓存控制等。
特别是：对缓存的处理，做到全局把握，优化内存资源，合理调优化。
同时：CYQ.Data 在性能调优方面表现出一定的优势。
包括：CYQ.Data 另一种优化方案：通过打印页面SQL，捕捉执行时间比较长SQL语句来进行针对性优化。
本节介绍：
杂说几句：
秋色园 QBlog 一直用Access，包括现在，目前mdb数据库已是600M的大小：
曾经尝试更换数据库：如：随说秋色园QBlog从Access升迁到MSSQL过程，不过最后还是没换，文中有说到原因就不重复了。
不久前买了个VPS，把秋色园搬到赌城“拉斯维加斯”。
同时也进行了多种数据库测试，先后跑了下：Access/mssql2000/2005/oracle/mysql/sqlite，等 CYQ.Data 数据框架 支持的数据库。
秋色园借助 CYQ.Data 数据框架 对一些不同数据库差异性函数和方法做了多数据库解析，无修改代码仅切换数据库链接，轻松顺利跑完多种数据库，这个以后再介绍。
虽然各种数据库都能跑，但目前还是没有更换数据库，仍在Access：
为了Access 10万文章的坚持，也是为了最大化的优化程序。
其实，最重要的原因，是VPS的512M的内存，经不起大数据的折腾。
老实说一句：Access其实并不快：
当Access上到单表几万的数据之后，单从查询想要快，很难。
秋色园 QBlog 首页基本速度为大约3秒左右执行显示，分页时，会慢一些5秒左右。
因此，提速不得不靠程序优化：
为缓存失效的背后，思考的两种方案：
方案一：产生后补缓存：接替快要失效的缓存，构造持续的缓存，数据及时更新有保障。
说明：
此方案简单的考虑了一下，并没有实施，因此也无深入去研究和实现这种方案。
猜测实现是应该可以的，只是需要点技术手段，大伙多想想。
不足：
对于IIS应用程序池内存回收时，会整体缓存失效，二次后补缓存，自然也失效，因此会无缓存的空白期。
所以，后来考虑了另一种方案，即方案二。
方案二：生成静态页面：临时接替失效的缓存，同时再产生新的缓存。
说明：
静态页面当了蜻蜓点水般的临时缓冲，这样就可以持续的保持高速的访问机制。
同时也可以避开内存回收的空白期，这是秋色园目前采用的方案。
不足：
比较难以控制新页面的产生，实时性不强，因为数据的更新关键在静态页面。
所以后面又想了很多招，来跳过静态页面的加载。
第二种方案的静态化的技术手段与难点：
1：如何生成静态页面？批量产生？后台程序？No...
2：静态页面如何呈现？访问xxx.html？No...
3：如何保障页面的更新？定时更新？No...
4：静态化甘愿做缓存的后补？....不好说，说不好，不说好......
具体的静态化技术方案解析：
一：如何生成静态页面
1：后台程序，点下按钮，批量生成？
以前做电子商务的时候，后台就是这么处理的，点下鼠标，批量生成产品的静态页面。
因为产品基本信息不怎么变，而且编辑人员就那么几个，重新编辑时就再生成一次html就好了。
不过秋色园不是这种方式，不太适用。
2：秋色园的方案：第一次受访，生成HTML
秋色园目前采用这种方式，因为将HTML当Xml方式的加载方式，要生成静态页面，只能说是相当的简单。
方法：只要在页面结束输出之前，将Xml的InnerXml保存到指定路径就可以了。
问题简化：如何构造指定保存路径了。
二：静态页面如何呈现
想象一下，当访问：http://www.cyqdata.com/qblog/article-detail-37431 的时候，
第一接手的是谁？是URLRewrite，它首先解析URL，然后决定跳转路径。
跳转可有两条路选：
1：增加一种逻辑，判断是否已生成html，根据条件跳转到静态化的html进行访问。
不过秋色园没有采用这种方式，其实也是可以尝试的。
2：将HTML当成缓存，直接读取并加载，然后继续后面的页面生命流程
基本逻辑如下：
if ( 尝试读取缓存) { 从缓存返回Document }
else if ( 尝试读取html){加载html返回Document ，并概率性线程，请求更新数据，同时产生新缓存}
else {原始的加载方式，依旧读取数据库，同时生成HTML页面}
PS：秋色园本来就是只有if和else，这里简单扩展出else if，也很容易。
三：保障页面的更新
1：原始的加载方式，上面的最后的 else 事件中，会生成HTML。
2：上面的 else if 事件中，有概率性事件请求，对于概率性事件，仍旧请求当前页面。
不过需要加标识，让它直接定位到最后的 else 事件，这样就可以产生新的更新页面了。
PS：
举例：如首页缓存3分钟，失效时，将进入 else if 事件中读取html并产生概率性事件，
如果第一次就中，即产生新的HTML，由于会再次产生的新缓存3分钟的旧数据，则实际6分钟更新一次数据呈现。
如果第一次不中，就再过3分钟进行抽奖，再3分钟再抽奖，同到中了后，再过3分钟，就看到新数据了。
四：平衡静态化与缓存的功效
一个页面基本100K，如果缓存页面，需要不少内存的说。
VPS 512M能缓存多少文章呢？还有系统其它N种开销，能省就省了。
因此缓存的过期和缓存时间是需要好好控制的，怎么合理控制，还看之前的文章：秋色园QBlog技术原理解析：性能优化篇：字节与缓存与并发(十二)
因此不能大面积的使用缓存，因此需要平衡使用，需要一个合理的使用策略。
今天刚升级了一下，当前秋色园的基本策略是：
1：首页：开启缓存+HTML
2：用户首页：开启缓存，关闭HTML
3：用户文章：关闭缓存，开启HTML
4：用户图片：关闭缓存，关闭HTML，少人用啊。
5：文章分类：开启缓存，关闭HTML
最后总结：
本节介绍了秋色园QBlog 实际中保持访问速度的内幕策略，下节继续介绍优化策略的再后续部分，敬请关注。
