Cache Manager

新快取文件取代原快取文件，不然則應刪除新快取文件，讓原快取文件能保留其 檔案最後修改時間與檔案大小，以能在HTTP 1.1 之快取機制下繼續使用。

但是，由於經由Web Switch 轉譯後送至 WADC 之 URL，與 Cache Manager 送至WADC 之 URL，皆為 Type A URL，而 WADC 對二者之處理方式又不相同，

因此 WADC 須辨認出是何者所發出的 Type A URL，而最簡易之方式便是檢查 Cache Directory 中是否已有相同 Type B URL 檔名之快取文件存在，若存在，則 表示WADC 所收到之 Type A URL 必是由 Cache Manager 所發出的，因此 WADC 只須將其所產生之動態網頁內容，以Type B URL 後加.cmr 副檔名之快取文件命 名方式，儲存於Cache Directory 中即可，不過由於此種檢查檔案是否存在之方式 在倘若有大量檔案等待檢查時，將會相當的費時，因此在未來的系統改進之中，

將可令Cache Manager 發出不同延伸格式之 Type A URL，以供作 WADC 辨識之 用。WADC 之處理流程如圖 3.8 所示。

圖3.8、WADC 之處理流程圖

立、常駐於伺服器作業系統之上，而在上述之系統元件中，僅有WADC 可與 Cache Manager 接觸，以讓 Cache Manager 了解該如何管理快取文件，但這也僅為 WADC 單方面之知會，Cache Manager 並不會作出任何直接的回應，因此，Cache Manager 與上述之系統元件並未有著直接的互動、交流，故不會影響、拖慢其它系統元件 之處理速度，因而可使Application-Level 動態網頁快取系統，能在滿足有效管理 快取文件之一般網頁快取系統設計準則下，持續保有高效率之服務品質，而這也 是Application-Level 動態網頁快取系統，不同於在 2.5 章節中曾探討的其它動態 網頁快取系統之處，而又由於Cache Manager 此種獨立作業之設計，將能使 Cache

Generating the dynamic content

Response the dynamic content with HTTP Cache-Control Header

Already Cached ?

Save the dynamic content as .cmr file

Notify the Cache Manager Save the dynamic content as

cache object

Yes No

Manager 無須非與網頁伺服器共處於同一主機上不可，而是能存在、運作於另一

主機之上，進而形成如圖 3.9 所示，由網頁伺服器在前端提供客戶端服務以及 Cache Manager 在後端管理、維護快取文件之獨立分工的叢集式（Cluster）動態 網頁快取系統，如此將更能達成最佳系統之整體服務效率與品質。

圖3.9、使用 Cache Manager 之叢集式動態網頁快取系統之設計示意圖

一旦Cache Manager 收到來自於 WADC 之知會後，即須開始進行管理快取 文件之工作，而其幾項較為主要之工作執掌如下：

1. 快取文件屬性值之取得與存放 2. 快取文件內容一致性之維護 3. 快取空間之置換

而Cache Manager 之各工作內容之說明如後。

首先是快取文件屬性值之取得與存放，對所有儲存在Cache Directory 中之個 別快取文件，Cache Manager 皆保存有快取文件屬性值，以下列出幾項較為重要

Cache Directory

Web Server Web Server Web Server

Cache Manager

之快取文件屬性值：

„ ID：快取文件皆以 Type B URL 語法命名後，儲存在 Cache Directory 之

內，而快取文件之檔案名稱即為ID 之值。

„ File Size：以 Byte 為單位之該快取文件檔案大小。

„ MD5 Value：MD5 主要供作判別快取快取文件檔案內容一致性之用。

„ Last Modified Time：該快取文件內容最近一次被修改之時間。

„ Last Access Time：該快取文件最近一次被讀取之時間。

„ Expiration Time：該快取文件內容逾期之時間。

„ Consistency Check Method：為 Cache Manager 用來維護該快取文件之內 容一致性的指定方式。

„ Check Time Interval：為 Cache Manager 用來維護該快取文件之內容一致 性的間隔時間。

而這些屬性值之取得方式，乃是由WADC 告知 Cache Manager，某快取文件 之ID、Consistency Check Method 與 Check Time Interval，而 Cache Manager 即會 主動自Cache Directory 中，取得該快取文件之 File Size、MD5 Value、Last Modified Time、Last Access Time，並依據現在伺服器系統之時間與 Check Time Interval，

計算出該快取文件之Expiration Time，以能在快取文件逾期之當時，立刻進行維 護快取文件之內容一致性的作業。

另一Cache Manager 之工作項目為快取文件內容一致性之維護，同時此也為 Cache Manager 最為重要之工作項目，由於動態網頁本身的特性，即在於其內容 有著經常性的改變，此種特性使得快取文件之內容一致性的維護工作要較靜態網 頁來的困難許多，不過正如同在 2.5.2.2 章節中所曾提及，動態網頁應用程式其 實與一般程式並無太大的不同，同樣有著固定之程式判斷處理流程（Process），

唯有當輸入值（Input）有所改變，輸出值（Output）才也會隨之改變，本研究便 憑藉此點，發展本快取系統之快取內容一致性的維護機制。

在觀察過許多動態網頁應用程式之後，整理出程式之輸入值，共可分為二大 類別：

„ Front-end Input

此類輸入值表示客戶端可主動進行操控，如客戶端透過URL 參數值給 予動態網頁應用程式輸入值，若程式只處理此類輸入值，只要客戶端給予相 同輸入值，各次程式執行後之輸出值必然皆會相同，在此種情況下，可以確 定的是快取文件之內容也必然不會改變，故無須進行快取文件之內容一致性 的維護作業。

„ Back-end Input

相反於Front-end Input，此類輸入值客戶端皆無操控之權力，如時間、

後端資料庫等等，若程式處理此類輸入值，則即使客戶端給予相同之 Front-end Input，各次程式執行後之輸出值未必皆會相同，故面對此種情況，

Cache Directory 中之快取文件便需 Cache Manager 來協助，以進行快取內容 一致性之維護作業。

是故，針對Back-end Input，Cache Manager 提供以下三種快取文件內容一致 性之維護機制作業方式：

„ Method for Regularly Changed Objects

此維護方式乃是針對時間之Back-end Input 而設，當快取文件應有之內 容變動有著固定週期時間，如固定每隔30 分鐘，即適用於此種維護方式。

現舉例說明此維護方式之運作機制，當WADC 知會 Cache Manager 之 訊息內容為”calculate.php!v1=2.html:T1800”時，Cache Manager 即會設定 calculate.php!v1=2.html 之 Consistency Check Method 為 Method for Regularly Changed Objects，以及 Check Time Interval 為 1800，並依據現在伺服器系統

之時間與Check Time Interval，計算出 calculate.php!v1=2.html 之 Expiration Time，然後再自 Cache Directory 中取得其餘 calculate.php!v1=2.html 之快取 文件屬性值，自此之後，Cache Manager 即會在 Expiration Time 時，也就是 每間隔1800 秒時，向網頁伺服器發出”/cache_dir/calculate.php?v1=2”之 Type A URL 請求，迫使 calculate.php 產生以”calculate.php!v1=2.html.cmr”為名之

新快取文件，此時Cache Manager 會以 MD5 比對新、舊快取文件之異同，

若二者之 MD5 不相同時，Cache Manager 即會更改新快取文件之檔名為舊 快取文件之檔名，以覆蓋舊快取文件，並重新取得、設定快取文件之屬性值，

而若是二者之MD5 相同，則 Cache Manager 會直接刪除新快取文件，不對 舊 快 取 文 件 有 任 何 更 動 ， 最 後 Cache Manager 會 重 新 設 定 calculate.php!v1=2.html 之 Expiration Time ， 以 能 繼 續 定 時 維 護 calculate.php!v1=2.html 之快取文件一致性。

„ Method for Irregularly Changed Objects with Notification

此維護方式乃是針對後端資料庫之Back-end Input 而設，如網頁應用程 式使用後端資料庫內之資料以產生動態網頁，若是後端資料庫內之資料有所 改變，則表示快取文件之內容也應當隨之改變，故Cache Manager 應當在此 時旋即更新快取文件之內容。

不過，由於本研究之範圍並未涉及至資料庫，故改以提供一通知Cache Manager 之方法，如 UNIX 系統之 Signal 與 Message Queue，使資料庫管理

員或是任何程式在更動資料庫內之資料的同時，能以此方法來通知 Cache Manager，知會 Cache Manager 應當立即更新某一特定快取文件之內容，以 維護、保持該快取文件之內容一致性。

現舉例說明此維護方式之運作機制，當WADC 知會 Cache Manager 之

訊 息 內 容 為”calculate.php!v1=2.html:N” 時 ， Cache Manager 即 會 設 定 calculate.php!v1=2.html 之 Consistency Check Method 為 Method for Irregularly Changed Objects with Notification ， 並 自 Cache Directory 中 取 得 其 餘 calculate.php!v1=2.html 之快取文件屬性值，至於 Check Time Interval 與 Expiration Time 在此維護方式中則無須使用，而每當 Cache Manager 再次收 到”calculate.php!v1=2.html:N”時，便會如同前述之維護方式，開始向網頁伺

服 器 發 出 Type A URL 請 求 ， 比 對 新 、舊 快 取 文 件 之 異 同 等， 以 使 calculate.php!v1=2.html 能持續保有最新之內容。

„ Method for Irregularly Changed Objects without Notification

此維護方式乃是為了解決快取文件之內容，雖明知其有固定週期時間之 變動，但此週期時間卻無人知曉之窘況，便可使用此種維護方式。

現舉例說明此維護方式之運作機制，當WADC 知會 Cache Manager 之 訊 息 內 容 為”calculate.php!v1=2.html:U” 時 ， Cache Manager 即 會 設 定 calculate.php!v1=2.html 之 Consistency Check Method 為 Method for Irregularly Changed Objects without Notification，並自 Cache Directory 中取得其餘 calculate.php!v1=2.html 之快取文件屬性值，至於 Check Time Interval 則採用 預設值，如30 秒，並以此計算出 Expiration Time，而後每至 Expiration Time，

Cache Manager 便會如同前述之維護方式，進行向網頁伺服器發出 Type A

URL 請求，比對新、舊快取文件之異同等工作，以使 calculate.php!v1=2.html 能持續保有最新之內容，並紀錄 calculate.php!v1=2.html 之內容變動次數，

而Cache Manager 會以此變動次數，以及 Cache Manager 自收到 WADC 之知 會至今的總共經歷時間，盡可能的計算出 calculate.php!v1=2.html 應有之變 動週期時間，並重新設定 Expiration Time，以能在 calculate.php!v1=2.html 之 內 容 應 當 更 新 之 際 ， 進 行 維 護 其 內 容 一 致 性 之 工 作 ， 使 calculate.php!v1=2.html 能持續保有最新之內容，圖 3.10 為此維護方式之示 意程式碼（Pseudo Code）。

至於內容並無固定變動週期時間之快取文件，則建議使用 Method for Regularly Changed Objects 維護方式，以較短之維護間隔時間，來盡可能的保持 快取文件之內容一致性。

Cache Manager 最後之工作項目為快取空間之置換，由於 Cache Manager 對 所有快取文件皆保有檔案大小之資訊，故可知Cache Directory 所使用儲存空間之 總合大小，當 Cache Directory 之儲存空間使用率達到一設定上限，如達到 95%

的快取空間置換上限時，Cache Manager 便會開始進行快取空間置換之作業。

Cache Manager 所使用的快取空間置換策略（Cache Replacement Policy）為 LRU（Least-Recently-Used），其為現今最為常見之置換策略，其方式為保留近期 曾被使用的快取文件，其餘已久未被使用的快取文件將會從快取空間中移除，此

圖3.10、Method for Irregularly Changed Objects without Notification 之 Pseudo Code

策略相當簡單易用，故不需耗費太多計算時間，同時可以獲得在短期內較佳的快 取擊中率（Cache Hit Ratio），即客戶端較能在快取系統中找到其所需要的快取文 件。

至於本研究選擇採用 LUR，乃是因動態網頁之特性與效率之考量，當開始 進行置換作業時，Cache Manager 便會讀取存在於 Cache Directory 中所有快取文 件的Last Access Time，從中找出久未被使用之快取文件並刪除之，此作業直到

PNT：每次周期（檢查 5 次所需的時間為一週期）內已經過的檢查次數 CNT：每次周期內網頁內容變動的次數

DED：每次檢查網頁內容的間隔時間（Second）

LMT：網頁內容最近變動的時間（UTC）

TCT：網頁內容變動的累計次數

HST：開始進行網頁內容變動次數累計的時間（UTC）

While Check { PNT++;

if page content change {

CNT++;

} if (PNT == 5) {

if(TCT == 0) // If Cache Manger doesn’t start to record {

if(CNT == 0) { DED *= 2; } // Page doesn’t have any change.

else if(CNT == 5) { DED /= 2; } // Page changes every check time.

else { TCT = CNT; HST = LMT; } // Start to record

}

else

{

TCT += CNT;

DED = (LMT - HST) / TCT; // DED = Total time / Total Change }

if(DED < 1) { DED = 1; }

PNT = CNT = 0;

}

sleep(DED); }