秋色园QBlog技术原理解析:性能优化篇:缓存总有失效时,持续的缓存方案(十四)

2年前 (2022) 程序员胖胖胖虎阿
234 0 0

文章回顾:

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技术原理解析:博客一键安装工具技术实现[附源码下载] --开源秋色园安装工具原理

2:如何安装部署秋色园CYQBlog站点

3:Windows7下如何安装部署秋色园CYQBlog站点

 

PS:秋色园QBlog 下载地址:http://www.cyqdata.com/download/article-detail-427

 

上两节小回顾:

在上两节中,介绍了 秋色园QBlog 在性能优化方面所做的一些工作:

比如:减少字节输出大小、写并发控制、缓存控制等。

特别是:对缓存的处理,做到全局把握,优化内存资源,合理调优化。

同时:CYQ.Data 在性能调优方面表现出一定的优势。

包括:CYQ.Data 另一种优化方案:通过打印页面SQL,捕捉执行时间比较长SQL语句来进行针对性优化。

 

本节介绍:

本节将介绍秋色园 QBlog 另一种网站优化方式:缓存失效后的后补方案,半静态化html,构造持续的缓存。

 

杂说几句:

秋色园 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秒左右。

 

因此,提速不得不靠程序优化:

为了提速,秋色园 QBlog 坚持从程序结构及控制上来下功能,因此 秋色园 QBlog 第一步 有了缓存机制。

不过缓存总有失效时,如何在缓存失效后,继续保持快速的访问?

 

为缓存失效的背后,思考的两种方案:

 

方案一:产生后补缓存:接替快要失效的缓存,构造持续的缓存,数据及时更新有保障

 

说明:

此方案简单的考虑了一下,并没有实施,因此也无深入去研究和实现这种方案。

猜测实现是应该可以的,只是需要点技术手段,大伙多想想。

 

不足:

对于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 实际中保持访问速度的内幕策略,下节继续介绍优化策略的再后续部分,敬请关注。

 

相关文章

暂无评论

暂无评论...