技巧 3：將數據和 HTML 緩存在 Web 服務器的磁盤上
有時，數據可能太多，無法都緩存在內存中�！疤�多”只是一個說法，這要看您想消耗多少內存，以及需緩存的項目數和檢索這些項目的頻率。在任何情況下，如果數據太多而無法都緩存在內存中，則考慮將數據以文本或 XML 文件緩存在 Web 服務器的硬盤上�？梢酝瑫r將數據緩存在磁盤和內存中，為您的站點建立最適宜的緩存策略。

注意當測量單個 ASP 頁的性能時，檢索磁盤上的數據可能不一定要比從數據庫檢索數據更快。但緩存會降低數據庫和網絡上的負載。在高負載的情況下，這樣做可大大改善總體吞吐量。當緩存開銷很大的查詢結果（如多表聯接或復合存儲過程）或大的結果集時，這是非常有效的。與往常一樣，要測試一下幾種方案的優劣。

ASP 和 COM 提供一些建立基于磁盤的緩存方案的工具。ADO 記錄集 Save() 和 Open() 函數保存和裝載磁盤中的記錄集。可以使用這些方法重新編寫上面 Application 數據緩存技巧中的代碼示例，用文件的 Save() 代替寫到 Application 對象中的代碼。

有一些其它組件可以用于文件：

Scripting.FileSystemObject 可使您創建、讀和寫文件。
與 Internet Explorer 一起提供的 Microsoft® XML 解析器 (MSXML) 支持保存和裝載 XML 文檔。
LookupTable 對象（例如，用在 MSN 上）是從磁盤裝載簡單列表的最好選擇。
最后，應考慮將數據的表示緩存在磁盤上，而不是數據本身。預先轉換的 HTML 可以用 .htm 或 .asp 文件存儲在磁盤上，超級鏈接可以直接指向這些文件。可以使用商用工具，如 XBuilder，或 Microsoft® SQL Server™ Internet 發布功能將產生 HTML 的過程自動化�；蛘�，您可以將 HTML 代碼片斷放在 .asp 文件中。還可以使用 FileSystemObject 從磁盤讀取 HTML 文件，或使用 XML 盡早轉換。

技巧 4：避免將非敏捷的組件緩存在 Application 或 Session 對象中
盡管將數據緩存在 Application 或 Session 對象中是一個好的做法，但緩存 COM 對象卻有嚴重的陷阱。通常，人們傾向于將經常使用的 COM 對象緩存到 Application 或 Session 對象中。很遺憾，許多 COM 對象（包括所有以 Visual Basic 6.0 或更低版本編寫的對象）當存儲在 Application 或 Session 對象時，會引起嚴重的瓶頸。

具體來講，當任何不敏捷的組件緩存在 Session 或 Application 對象時，將引起性能瓶頸。敏捷的組件是被標記為 ThreadingModel=Both 的組件，它聚集 Free-threaded marshaler (FTM)；或被標記為 ThreadingModel=Neutral 的組件。（Neutral 模型是 Windows® 2000 和 COM+ 的新增模型。） 下列組件不是敏捷的：

自由線程的組件（除非它們聚集 FTM）。
單元線程組件。
單線程組件。
配置的組件（Microsoft Transaction Server (MTS)/COM+ 庫和服務器程序包/應用程序）不是敏捷的，除非它們是 Neutral 線程。單元線程組件和其它非敏捷的組件在頁作用域內是最適合的（即，它們在單個 ASP 頁上創建和銷毀）。

在 IIS 4.0 中，被標記為 ThreadingModel=Both 的組件被認為是敏捷的。在 IIS 5.0 中，只有這一點還不夠。組件必須不僅被標記 Both，還必須聚集 FTM。有關敏捷性的文章講述了如何使以 Active Template Library 編寫的 C++ 組件聚集 FTM。要注意如果組件緩存界面指針，那么那些指針本身必須是敏捷的，或必須存儲在 COM 共用界面表 (GIT) 中。如果您不能重新編譯 Both 線程組件以聚集 FTM，那么您可以將組件標記為 ThreadingModel=Neutral。或者，如果您不想讓 IIS 執行敏捷性檢查（因此，您可以允許非敏捷的組件存儲在 Application 或 Session 作用域中），您可以在配置數據庫中將 AspTrackThreadingModel 設置為 True。不建議更改 AspTrackThreadingModel。

如果您想將以 Server.CreateObject 創建的非敏捷的組件存儲在 Application 對象中，IIS 5.0 將出現一個錯誤。您可以在 Global.asa 中使用 <object runat=server scope=application ...> 避免這一錯誤，但不建議這樣做，因為這會導致匯集和串行化，關于這一點將在下面講述。

如果您緩存非敏捷的組件會出現什么毛�。烤彺嬖� Session 對象中的非敏捷的組件將 Session 鎖定于 ASP 工作者線程。ASP 維護一個工作者線程池來處理請求。通常情況下，一個新請求總是由第一個可用的工作者線程來處理。如果 Session 被鎖定于一個線程，那么請求必須等到其相關的線程可用為止。這里有一個類比，也許會有所幫助：您去一家超級市場，挑選了一些商品，并在 #_3 收款臺付款。其后，每當您在那家超級市場為商品付款時，您總是必須在 #_3 收款臺付款，即使其它收款臺前排隊的人較少或者沒有人排隊，也是如此。

將非敏捷的組件存儲在 Application 作用域對性能的影響甚至更壞。ASP 必須創建一個特殊的線程運行存儲在 Application 作用域中的非敏捷組件。這會有兩個結果：所有調用都必須匯集到此線程，且所有調用都排成長隊�！皡R集”的意思是參數必須存儲在內存的共享區域；執行一個開銷很大的到特殊線程的上下文切換；執行組件的方法；將結果匯集到共享區域；執行另一個開銷很大的上下文切換，將控制返回到原始的線程。“串行化”意思是指每次只運行一個方法。兩個不同的 ASP 工作者線程不能同時在共享組件上執行多個方法。這樣就杜絕了并發性，特別是在多處理器計算機上。更糟的是，所有非敏捷的 Application 作用域的組件共享一個線程（主機 STA），因此串行化的影響甚至更顯著。

如之奈何？下面是一些一般的規則。如果您使用 Visual Basic (6.0) 或更早版本編寫對象，那么不要將它們緩存在 Application 或 Session 對象中。如果您不知道對象的線程模型，不要緩存它。不要緩存非敏捷的對象，而應在每個頁面創建和釋放它們。對象直接在 ASP 工作者線程上運行，因此沒有匯集或串行化。如果 COM 對象在 IIS 服務器上運行，且如果它們不花長時間初始化和刪除，性能尚可。注意單線程對象不應該這樣使用。小心 - VB 可創建單線程對象！如果您必須這樣使用單線程對象（如 Microsoft Excel 電子表格），別指望會有很高的吞吐量。

當 ADO 被標記為自由線程，ADO 記錄集可以安全地緩存。要將 ADO 標記為自由線程，使用 Makfre15.bat 文件，該文件通常位于目錄 \\Program Files\Common\System\ADO 中。

警告 如果您使用 Microsoft Access 作為數據庫，不應將 ADO 標記為自由線程的。ADO 記錄集也必須切斷連接。一般來說，如果您不能控制站點中的 ADO 配置（例如，您是一個獨立的軟件廠商 [ISV]，向管理他們自己的配置客戶銷售 Web 應用程序），最好不要緩存記錄集。

詞典組件也是敏捷的對象。LookupTable 從數據文件中裝載其數據，可用于組合框數據和配置信息。Duwamish Books 中的 PageCache 對象可提供詞典語法，Caprock Dictionary 也可提供。這些對象或其派生對象可以構成有效緩存策略的基礎。注意 Scripting.Dictionary 對象不是敏捷的，不應該存儲在 Application 或 Session 作用域中。