• 沒有找到結果。

第三章 系統設計與實作

3.1 系統設計概念

故若要取得動態網頁之內容以快取之,在網頁伺服器端必然不會是件難事,同時 當動態網頁之內容有所變動時,也必然能在網頁伺服器端首先察覺,因此,若要 能有效的快取動態網頁,並避免內容一致性之問題發生,以解決動態網頁所衍生 之相關問題,網頁伺服器端將會是最合適的解決方式之研發起點。

不過,由於網頁伺服器之設計主旨並非在於快取網頁,故對於在快取網頁時 所需具備之處理流程與伺服器元件全然缺乏,而部分網頁伺服器雖有快取網頁之 能力,如Apache 網頁伺服器,其雖有著 mod_proxy 與 mod_cache 二個快取模組,

但其可快取之網頁種類,也僅限於靜態網頁而非動態網頁,同時,本研究認為,

對網頁伺服器而言,最自然且效率應為最佳之處理方式,即為直接取用靜態網 頁,過多或過於複雜的伺服器處理與快取之流程與元件,在未能真正達成最佳設 計規劃之下,將只會更進一步拖慢網頁伺服器之處理速度而已,因此,本研究將 以網頁伺服器取用靜態網頁之處理流程,作為研發動態網頁快取系統時之設計藍 本,並在更動原有網頁伺服器處理流程需為最小之前提下,增添快取動態網頁時 所需之伺服器元件,使網頁伺服器不僅能快取動態網頁,且能如同取用靜態網頁 一般,直接取用在快取動態網頁後所成之快取文件,以回覆客戶端之請求。

而在經由上述種種設計之考量下,本研究之動態網頁快取系統之初始設計概 念與運作流程即如圖3.1 所示,其中的 Cache Directory 為存放所有快取文件之所 在,而本研究僅在網頁伺服器處理客戶端請求之流程前加上一個判別樞紐,作為

圖3.1、系統設計概念圖

判別在 Cache Directory 中,有無存在客戶端所要求的動態網頁之快取版本,若 有,則開始進行伺服器處理靜態網頁之程序,自Cache Directory 取出快取文件,

以此回覆予客戶端,而若樞紐之判別結果為無,則開始進行伺服器處理動態網頁 之程序,首先執行動態網頁應用程式,以產生動態網頁之內容,並在該內容之前 端加上所需之HTTP Cache-Control Header,以此先回覆予客戶端,隨後將該內容 存成快取文件,放置於Cache Directory 中,使得若再有相同的客戶端請求,網頁 伺服器即可自動進行靜態網頁之處理程序,以能快速的回覆客戶端。

是故,此種設計不僅簡單,同時也極有效率,將能大幅的縮短客戶端之等待 時間,並將可降低伺服器之資源耗用程度,而能較先前未使用此系統設計時,大

Web Server If have cached

dynamic web

page Web App

Cache Directory HTML Page

Request

Response No

Yes Output

Save

With HTTP Cache-Control Header

幅提升網頁伺服器之處理能力,而為了實現此設計概念,本研究先後進行了二種 不同實作層次之動態網頁快取系統設計 -- Application-Level 與 Server-Level,而 此二套快取系統將在本章之後續章節分別詳細介紹。