一、什麼是ASP緩存/為什麼要緩存
其實當你的web站點采用asp技術建立的初期，可能會感覺到的是asp動態網頁技術帶來的便利性，以及隨意修改性、自如的http控制。但隨著訪問量的增加，你一定會發現自己的站點訪問速度會越來越慢，IIS重新啟動得越來越頻繁。那麼，你一定想怎麼優化你的ASP程序，諸如更換性能更優異的數據庫、建立索引、編寫存儲過程等等。這些措施有些不需要增加成本壓力，有些則成本壓力很大（譬如叢Access到SQL），而且效果還不一定。
面對web訪問壓力，我認為最經濟的辦法是利用緩存優化技術來實現緩解web的服務壓力。
Web訪問量增加通常意味著以下資源需求的快速增長：
1、網卡流量增加，需要消耗更多的CPU處理網絡流量和網絡I/O線程。
2、需要更頻繁的打開/關閉數據庫連結（如果使用數據庫技術—通常ASP都會采用數據庫作為數據存儲），嚴重消耗資源的事物數量、以及事務相互競爭資源引起的死鎖、會增加網絡I/O或者CPU消耗。
3、如果采用session的話，IIS為了維持狀態，會消耗更多內存，而內存消耗可能會引發物理內存不夠，引起物理內存同輔存間的頻繁交換，從而引起代碼執行的停頓，web響應阻滯。
4、由於訪問的不到及時響應，會引起網頁訪問故障，導致用戶刷新，從而加劇CPU、內存等資源需求。
實際上，考慮通常的web應用程序，很多時候的動態代碼執行是不必要的。
二、ASP緩存的分類
擅自總結，ASP的緩存可以分為兩類：
1、文件緩存
所謂文件緩存，就是根據邏輯判斷，一段時間內某個ASP的特定執行將不會有很大的變動，因而將內容以靜態Html的形式存放，然後以web的重定向技術讓客戶端訪問靜態文件，以達到減少CPU、數據庫資源等的需求。這樣的應用很多，譬如很多論壇就是在回復貼子的時候將整個貼子重新生成一個靜態文件，然後進行重定向的，例如 donews.com的論壇。該成靜態還有一個副作用（好處）--可以很容易被google等搜索引擎收錄。一些所謂新聞發布系統的都采用了此技術。
2、文件片斷緩存
所謂文件緩存，也是基於邏輯判斷，某部分數據（通常是需要消耗資源的大容量數據庫查詢取得）在一定時間內不會改變，所以我們可以將這些數據利用文件的形式進行存儲，當需要時候，可以通過讀取文件來獲取數據，避免增加數據庫的負擔。例如，我們通常將一些數據以xml格式存儲，然後利用xslt技術實現顯示（xml處理通常需要大量CPU資源，所以通常是IE直接讀取XML到客戶端在客戶的CPU上進行處理）。CSDN的論壇就是這樣處理的。
3、主存緩存
除此之外，還可以考慮在內存中處理緩存，將需要及時響應的內容存儲在內存中，一旦訪問需求，立即從快速的貯存中輸送出去。如果極大量的訪問需求集中在幾個少量的頁面或者主存足夠多，我想采用主存緩存一定可以大幅度提高web訪問性能。
三、如何實現/使用緩存
實現緩存需要考慮以下問題：
1、哪些頁面會在短時間內不會改變？
分析自己的站點，這樣的頁面很多。譬如一個站點通常都有新聞資訊類的欄目，這些欄目通常都是站點維護人員在一天的某個時間發布資料，之後很少改動頁面。那麼這些頁面就適合於采用靜態文件緩存。實際上，所謂新聞發布系統就是這麼做的，那麼那也可以參考這些系統的思想改造自己的原有動態ASP頁面。
2、那些頁面針對全部訪問者都采用同一個邏輯生成（也就是不區分訪問者）。
除了新聞資訊之類的欄目所有訪問者都看一個界面外，論壇等消耗資源的應用一般也可以設計成統一邏輯生成（同一個貼子，張三李四看的都一樣），針對這類應用頁面我們也可以采用靜態緩存來實現。也可以考慮將數據片斷化，利用腳本技術在服務器處理能力之外也就是客戶端浏覽器進行處理。
3、采用緩存的代價和收獲。
主要就是“空間換（響應）時間”。利用緩存技術將之後頻繁需要的內容進行預處理，使之提高web服務器響應能力，更重要贏得訪問者的歡心。
代價就是web空間需求增加，同時又可能影響到訪問效果。
但我認為適當的緩存，是利大於弊的。
4、那些地方不適宜采用緩存
動態查詢頁面，每個人的查詢內容不一樣，所以顯示結果不大一樣，所以不大可能將查詢結果生成緩存，所以采用緩存較為復雜且緩存利用率底下，造成管理成本上什（假設你緩存了1000個查詢關鍵字，那麼管理這些關鍵字同緩存的對應也是麻煩事）。
四、實例分析
假設一個建議論壇的原有布局如下：
根目錄下：
default.ASP首頁，一般是精華、推薦之類
listBorad.ASP 該文件列出全部分欄目的名稱和介紹，如果攜帶參數MainBID就表示要列出板塊下的欄目
listThread.ASP該文件如果不攜帶任何參數表示列出全部的貼子，攜帶MainBID表示列出某塊的全部貼子。如果攜帶subBID表示列出具體欄目的貼子。如果攜帶page參數表示分頁列出主題。
VIEwThread.ASP 列出某個貼子內容。我們假設貼子顯示為一個發言，任意跟貼全部列在後面。ID參數為要顯示的貼子。
Reply.ASP 回應某個貼子，攜帶參數Id回應某個貼子
其它的暫不討論。
以上，我們可以看到，如果全部是采用原始的ASP/PHP來做，那幾乎每一個ASP文件的執行都需要數據庫操作，頻繁的查詢，多表查詢。要知道查詢數據庫最終會帶來性能的下降，響應速度下降，帶給訪問者緩慢的浏覽影響，不利於web的質量。更重要的是對於甲乙兩個人來將，他們訪問VIEwThread.ASP之類的如果ID一致，那麼很多時候他們會看到同樣的內容（他們的浏覽器收到的Html代碼幾乎一樣），但是為了這“同樣的內容”，服務器需要打開數據庫連結、查詢，讀取紀錄，顯示，關閉紀錄、數據庫連結。。。。以下列的消耗服務器資源的操作，如果是更多的人來訪問，最終的結果是這些人加劇消耗服務器資源。實際上，這些為了“同樣的內容”所做的重復勞動是可以利用緩存技術進行優化避免的。譬如：
在reply.ASP提交內容後，我們立即調用生成靜態的功能，將整個貼子內容存儲為vIEwThread_xxxx.htm之類的靜態Html文件，再通常情況下訪問vIEwThread.ASP?ID=xxxx的時候，系統自動redirect到對應的靜態文件vIEwThreadxxxx.htm去。這樣，當一個貼子沒有最新發布時候，他始終是靜態內容提供給浏覽者；一旦有了新的提交，將會更新到靜態文件中去，這樣，將會節省很多次數據庫操作，大大提高響應速度。
listBorad.asp也可以實施靜態化。我們可以分析其可能攜帶的參數，將緩存文件名設定為listBoard_xx.htm，在增加新的欄目時候進行更新listBoard_xxx.htm。listThread.asp也類似，只不過由於其參數更多，所以緩存文件也會很多。擊若要緩存listThread.asp? subBID=xxx&page=2，那麼對應的靜態文件是listThread_xxx_p2.htm。default.ASP也一樣。
那麼如何判斷什麼時候更新？在什麼時機更新？
討論listThread.asp? subBID=xxx&page=2，我們在執行listThread.ASP俄時候提取subID和page，然後探測listThread_xxx_p2.htm是否存在，如果不存在就調用靜態生成功能進行生成該文件，最終重定向到此靜態文件。注意，此處的不存在就意味著出現了新的內容需要我們進行更新。
那如何造成文件不存在呢？刪除。我們在發表一個新的貼子、刪除貼子、移動貼子的時候我們可以將類似listThread_xxx_p2.htm之類的靜態文件全部刪除。這樣就通知了何時要進行緩存。
現在還剩下一個問題，如何生成靜態文件？
我們注意到，之前我們提到的“同樣的內容”。我們可以將改造前的default.asp、listThread.asp等拷貝一個副本，取名為default_d.asp、listThread_2.asp，且在同一個目錄中（理論上listThtrad.asp?subID=123同LISTtHREAD_D.ASP?SUBID=123的訪問結果會是同樣的內容），這樣我們在需要生成靜態文件的邏輯中，通過WEB訪問請求的方式調用改造前的副本，得到html代碼，並存儲為靜態文件。這個web請求實際上相當於在任何真實浏覽者訪問靜態內容之前，由服務器自身現察看將會輸出的Html，然後返回這些代碼，利用文件操作功能存儲為靜態文件。這樣，緩存文件就在真正浏覽者之前被創建。
這樣的方案幾乎不觸動原來的布局，幾乎不會造成因為改造出現404之類的錯誤。其次，靜態文件也會幫助你的站點容易被被google之類的搜索引擎收錄。何樂而不為？
最後，提醒，通過web訪問，ASP編程環境下，很多人采用xmlHTTP組件訪問，這會造成很多問題。xmlhttp自身會cache請求的資源，導致我們通過此組件請求得到的內容不是最新的，造成邏輯上的混亂。所以，應當選擇XML Server http對象或者winhttp組件來實現web請求資源。
80摘後語：實現緩存技術主要有幾種關鍵的東西，
服務器端application，適用於多個頁面間存在較多不太經常更新的元素；
生成Html靜態文件，通常會采用模版技術，通過FSO或ADOStream生成靜態文件，通常都適用於很多人看到的都是同樣的頁面內容的情況，如文章、論壇帖子等；
其他
其實最重要的還是根據自己系統的需求來決定采用何種技術，盡量少地減少查詢數據庫的次數，減輕數據庫壓力，當然，一般會以犧牲空間做代價。
另外，正在考慮是否能夠采用客戶端的緩存來提高效率？
