技巧 5：不要將數(shù)據(jù)庫連接緩存在 Application 或 Session 對象中
緩存 ADO 連接通常是很糟糕的策略。如果一個 Connection 對象存儲在 Application 對象中，并在所有的頁面中使用，那么所有頁面將爭搶這一連接。如果 Connection 對象存儲在 ASP Session 對象中，那么將為每個用戶創(chuàng)建數(shù)據(jù)庫連接。這就會使連接池的優(yōu)勢蕩然無存，并給 Web 服務(wù)器和數(shù)據(jù)庫帶來不必要的壓力。

可以不緩存數(shù)據(jù)庫連接，而是在使用 ADO 的每個 ASP 頁面中創(chuàng)建和刪除 ADO 對象。這是很有效的，因為 IIS 內(nèi)嵌了數(shù)據(jù)庫連接池。更準(zhǔn)確地說，IIS 自動啟用 OLEDB 和 ODBC 連接池。這就能確保在每個頁面上創(chuàng)建和刪除連接將是有效的。

因為連接的記錄集存儲一個到數(shù)據(jù)庫連接的引用，所以您不應(yīng)將連接的記錄集緩存在 Application 或 Session 對象中。但是，您可以安全地緩存斷開連接的記錄集，它們不保存到其數(shù)據(jù)連接的引用。要斷開記錄集連接，執(zhí)行下面的兩個步驟：

Set rs = Server.CreateObject(?ADODB.RecordSet?)
rs.CursorLocation = adUseClient ' step 1

' Populate the recordset with data
rs.Open strQuery, strProv

' Now disconnect the recordset from the data provider and data source
rs.ActiveConnection = Nothing ' step 2


有關(guān)連接池的更詳細信息，可以在 ADO 和 SQL Server 參考資料中找到。

技巧 6：合理地使用 Session 對象
既然我們已經(jīng)討論了緩存在 Application 和 Session 中的優(yōu)點，現(xiàn)在開始討論避免使用 Session 對象的問題。正如下面所討論的，當(dāng)與忙的站點一起使用時，Session 有幾個缺點�！懊Α钡囊馑家话闶侵敢幻腌娨�求幾百頁面或成千上萬同時用戶的站點。這個技巧對于必須水平擴展的站點 - 即，那些利用多臺服務(wù)器以處理負載或?qū)崿F(xiàn)容錯的站點 - 甚至更重要。對于較小的站點，諸如 Intranet 站點，要想實現(xiàn) Session 帶來的方，必然增大系統(tǒng)開銷。

簡言之，ASP 自動為每個訪問 Web 服務(wù)器的用戶創(chuàng)建一個 Session。每個 Session 大約需要 10 KB 的內(nèi)存開銷（最主要的是數(shù)據(jù)存儲在 Session 中），這就使所有的請求都減慢。在配置的超時時段（通常是 20 分鐘）結(jié)束以前，Session 一直保留有效。

Session 的最大的問題不是性能，而是可擴展性。Session 不能跨越幾臺 Web 服務(wù)器，一旦在一臺服務(wù)器上創(chuàng)建 Session，其數(shù)據(jù)就留在那兒。這就意味著如果您在一個 Web 服務(wù)器群使用 Session，您必須設(shè)計一個策略，將每個用戶請求始終發(fā)到用戶 Session 所在的那臺服務(wù)器上。這被稱為將用戶“粘”在 Web 服務(wù)器上。術(shù)語“粘性會話”就是從這里派生而來的。如果 Web 服務(wù)器崩潰，被“粘住的”用戶將丟失他們的會話狀態(tài)，因為會話不是粘到磁盤上。

實現(xiàn)粘性會話的策略包括硬件和軟件解決方案。諸如 Windows 2000 Advanced Server 中的網(wǎng)絡(luò)負載平衡和 Cisco 的 Local Director 之類的解決方案都可以實現(xiàn)粘性會話，代價是要損失一定程度的可擴展性。這些解決方案是不完善的。不建議此時部署您自己的軟件解決方案（我們過去常常使用 ISAPI 篩選器和 URL 轉(zhuǎn)換等等）。

Application 對象也不跨越多臺服務(wù)器，如果您必須跨越 Web 服務(wù)器群共享和更新 Application 數(shù)據(jù)，您必須使用后端數(shù)據(jù)庫。但是，只讀 Application 數(shù)據(jù)在 Web 服務(wù)器群中仍是有用的。

如果只是因為要增加運行時間（處理故障轉(zhuǎn)移和服務(wù)器維護），大多數(shù)關(guān)鍵任務(wù)站點至少需部署兩臺 Web 服務(wù)器。因此，在設(shè)計關(guān)鍵任務(wù)應(yīng)用程序時，必須實現(xiàn)“粘性會話”，或干脆避免使用 Session，以及任何其它將用戶狀態(tài)存儲在單個 Web 服務(wù)器上的狀態(tài)管理技術(shù)。

如果您不使用 Session，一定要將它們關(guān)閉。您可以通過 Internet Services Manager，為應(yīng)用程序執(zhí)行此操作（參見 ISM 文檔）。如果您決定使用 Session，您可以采用一些方法減輕它們對性能的影響。

您可以將不需要 Session 的內(nèi)容（如幫助屏幕，訪問者區(qū)域等等）移到另一個關(guān)閉了 Session 的 ASP 應(yīng)用程序中。您可以逐頁提示 ASP，您不再需要該頁面上的 Session 對象，使用以下放在 ASP 頁面最上面的指令：

<% @EnableSessionState=False %>


使用這一指令有一個很好的理由是，這些 Session 在框架集方面存在一個有意思的問題。ASP 保證任何時候 Session 只有一個請求執(zhí)行。這樣就確保如果瀏覽器為一個用戶請求多個頁面，一次只有一個 ASP 請求接觸 Session，這樣就避免了當(dāng)訪問 Session 對象時發(fā)生的多線程問題。很遺憾，一個框架集中的所有頁面將以串行方式顯示，一個接一個，而不是同時顯示。用戶可能必須等候很長時間，才能看到所有的框架。該故事的寓意：如果某些框架集頁面不依靠 Session，一定要使用 @EnableSessionState=False 指令告訴 ASP。

有許多管理 Session 狀態(tài)的方法，可替代 Session 對象的使用。對于少量的狀態(tài)（少于 4 KB），我們通常建議使用 Cookies、QueryString 變量和隱式變量。對于更大數(shù)據(jù)量，如購物小車，后端數(shù)據(jù)庫是最適合的選擇。有關(guān) Web 服務(wù)器群中狀態(tài)管理技術(shù)的文章很多。有關(guān)詳細信息，請參見 Session 狀態(tài)參考資料。

技巧 7: 將代碼封裝在 COM 對象中
如果您有許多 VBScript 或 JScript，您可以經(jīng)常將代碼移到編譯的 COM 對象中，從而可改善性能。編譯的代碼通常比解釋的代碼運行得更快。編譯的 COM 對象可以通過“早綁定”訪問其它 COM 對象，與腳本使用的“晚綁定”相比，“早綁定”是調(diào)用 COM 對象的更有效方法。

將代碼封裝在 COM 對象中還有一些優(yōu)點（除性能之外）：

COM 對象有利于將表示邏輯與業(yè)務(wù)邏輯分開。
COM 對象可以保證代碼重復(fù)使用。
許多開發(fā)人員發(fā)現(xiàn)以 VB、C++ 或 Visual J++ 編寫的代碼比 ASP 更容易調(diào)試。
COM 對象也有缺點，包括初始開發(fā)時間和需要不同的程序設(shè)計技巧。注意封裝少量的 ASP 可能引起性能下降，而不會得到性能改進。這種情況通常在少量的 ASP 代碼被封裝進 COM 對象時發(fā)生。在這種情況下，創(chuàng)建和調(diào)用 COM 對象的系統(tǒng)開銷超過了編譯的代碼的優(yōu)點。應(yīng)反復(fù)地試驗，以確定什么樣的 ASP 腳本和 COM 對象代碼的組合產(chǎn)生最好的性能。注意，與 Microsoft Windows NT&reg; 4.0/IIS 4.0 相比，Windows 2000/IIS 5.0 中在腳本和 ADO 性能方面有了很大的改進。因此，隨著 IIS 5.0 的推出，編譯代碼比 ASP 代碼的性能優(yōu)勢有所降低。

有關(guān)在 ASP 中使用 COM 的優(yōu)點和缺點的詳細討論，參見 ASP Component Guidelines and Programming Distributed Applications with and Microsoft Visual Basic 6.0。如果您部署 COM 組件，以負荷對它們進行測試特別重要。事實上，理所當(dāng)然應(yīng)對所有的 ASP 應(yīng)用程序進行負荷測試。