秋色園QBlog技術原理解析：效能最佳化篇：緩衝總有失效時，持續的緩衝方案(十四)

文章回顧：

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 實際中保持訪問速度的內幕策略，下節繼續介紹最佳化策略的再後續部分，敬請關注。