秋色園QBlog技術原理解析:性能優化篇:緩存總有失效時,構造持續的緩存方案(十四)

轉載自:http://www.cyqdata.com/qblog/article-detail-38993html


文章回顧:mysql

1: 秋色園QBlog技術原理解析:開篇:總體認識(一) --介紹總體文件夾和文件的做用sql

2: 秋色園QBlog技術原理解析:認識整站處理流程(二) --介紹秋色園業務處理流程數據庫

3: 秋色園QBlog技術原理解析:UrlRewrite之無後綴URL原理(三) --介紹如何實現無後綴URL緩存

4: 秋色園QBlog技術原理解析:UrlRewrite之URL重定向體系(四) --介紹URL如何定位處處理程序性能優化

5: 秋色園QBlog技術原理解析:Module之頁面基類設計(五) --介紹建立基類和自定義生命週期併發

6: 秋色園QBlog技術原理解析:Module之頁面基類-生命週期流程(六) --介紹基類生命週期內部業務oracle

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

上[2]節回顧:

上兩節中,介紹了 秋色園QBlog 在性能優化方面所作的基礎工做:

減小字節輸出大小、寫併發控制、緩存控制等。

特別是對緩存的處理,作到全局把握,優化內存資源,合理調優化。

CYQ.Data 在性能調優方面表現出必定的優點。

同時又介紹了另外一種優化方案:經過打印頁面SQL,捕捉耗時語句長的進行鍼對性優化。

本節介紹:

本節將介紹秋色園  QBlog  再更進一步的網站優化方式:緩存失效後的後補方案,靜態化的html。

秋色園 QBlog 一直用Access,目前已超過600M的大小:

曾經嘗試更換數據庫:如:2011年03月14日---隨說秋色園QBlog從Access升遷到MSSQL過程,不過最後仍是沒換成,緣由文中有說到,就不重複了。

前不久買了個VPS,把秋色園搬到賭城「拉斯維加斯」,同時也進行了多種數據庫測試,前後跑了下:Access/mssql2000/2005/oracle/mysql/sqlite,等 CYQ.Data 數據框架 支持的數據庫。

藉助 CYQ.Data 數據框架  對一些不一樣數據庫差別性函數和方法作了多數據庫解析,秋色園無需修改代碼僅靠切換數據庫連接,就輕鬆轉移數據庫順利跑完,這個之後再介紹。

雖然各類數據庫都能跑,但目前仍是沒有更換數據庫,持續的跑access:

爲了Access 10萬文章的堅持,也是爲了最大化的優化程序。

其實,最重要的緣由,是VPS的512M的內存,經不起大數據的折騰。

Access其實速度並不快:

當Access上到單表幾萬的數據以後,單從查詢想要快,很難。

基本速度爲大約3秒左右執行完一個秋色園 QBlog 首頁,分頁,會慢一些5秒左右。

提速靠程序優化:

爲了提速,秋色園 QBlog 堅持從程序結構及控制上來下功能,因此 秋色園 QBlog 第一步 有了緩存機制。

不過緩存總有失效時,如何在緩存失效後,繼續保持快速的訪問?

 

緩存失效背後的方案:

方案一:

產生後補緩存:接替快要失效的緩存,保持持續的緩存,同時保障頁面的及時更新。

說明:

不過只是簡單的考慮了一下,並無深刻去研究和實現這種方案。

實現是確定能夠的,須要點技術手段,大夥多想一想。

不足處:

對於應用程序池內存回收時,會總體緩存失效,後補天然也失效,此時還會產生空白期。

因此,後來考慮了另外一種方案。

方案二:

生成靜態頁面:臨時接替失效的緩存,同時再產生新的緩存。

說明:

如此一來,靜態頁面當了臨時緩衝,這樣就能夠持續的保持高速的訪問機制。

同時也能夠避開內存回收的空白期,這是秋色園目前採用的方案。

不足處:

比較難以控制新頁面的產生,實時性不強。

因此後面又想了不少招,來跳過靜態頁面的加載。

 

靜態化的技術手段與難點:

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頁面}

三:如何保障頁面的更新

1:原始的加載方式,上面的最後的 else  事件中,會生成HTML。

2:上面的 else if   事件中,有機率性事件請求,對於機率性事件,仍舊請求當前頁面。

不過須要加標識,讓它直接定位到最後的 else  事件,這樣就能夠產生新的更新頁面了。

PS:

首頁好比緩存3分鐘,失效時,進入 else if   事件中讀取html,同時產生機率性事件,

若是第一次就中了,加上再次產生的新緩存3分鐘,則實際6分鐘更新一次數據呈現。

四:平衡靜態化與緩存的功效

基本一個頁面就100K,512M能緩存多少文章呢?還有系統其它N種開銷,能省就省了。

所以不能大面積的使用緩存,所以須要平衡使用,將靜態化提高到一個重要位置使用。

目前秋色園的基本策略是:

1:首頁:開啓緩存+HTML

2:用戶首頁:開啓緩存,關閉HTML

3:用戶文章:關閉緩存,開啓HTML

4:用戶圖片:關閉緩存,關閉HTML,少人用啊。

5:文章分類:開啓緩存,關閉HTML

總結:

本節介紹了秋色園QBlog 實際中保持訪問速度的策略,下節繼續介紹優化策略的再後續部分,敬請關注。

相關文章
相關標籤/搜索