技巧
技巧 6：妙用 Session 對象 在肯定了在 Applications 和 Sessions 中緩衝的優點之後，我們建議您避免使用 Session 對象。下面將會談到，當用於忙碌網站時，Sessions 有幾個缺點。所謂忙碌，通常是指網站每秒請求數百頁或同時有數千個使用者。該技巧對於必須進行水平擴充的網站，即那些利用多個伺服器來適應負載或執行容錯功能的網站來說，更加重要。對於較小的網站，如 intranet 網站，Sessions 的便利，與開銷相比也是值得的。
為了翻新，ASP 自動為每個訪問 Web 服務器的使用者建立一個 Session。每個 Session 有大約 10 KB 記憶體開銷（在儲存在 Session 中的任何資料中是最高的），並使所有的請求都慢了一點。Session 一直保持活動狀態，直到達到可配置的逾時（通常 20 分鐘）為止。
Session 最大的問題不是效能而是延展性。Session 不能跨越 Web 服務器；一旦在一個伺服器上建立了 Session，它的資料就保持在那裡。這意味著，如果您在 Web 領域中使用 Sessions，您將不得不為每個使用者的請求設計一種策略，以便始終將這些請求引向使用者的 Session 所在的伺服器。這被稱為將使用者“粘”到 Web 服務器上。術語“粘性會話”即來源於此。由於 Session 沒有保持到磁碟上，所以，當 Web 服務器崩潰時，被“粘住”的使用者將丟失他們的 Sessions 狀態。
用於實施粘性會話的策略包括硬體和軟體解決方案。如 Windows 2000 Advanced Server 中的網路Server Load Balancer解決方案和 Cisco 公司的“本地指向器”解決方案可以實施粘性會話，但以犧牲一些延展性為代價。這些解決方案並不完美。我們不主張您現在全盤推翻您的軟體解決方案（我們過去常用 ISAPI 篩選器和 URL 矯直對方案進行檢查）。
Application 對象也不能跨越伺服器；如果您需要在 Web 領域內共用並更新 Application 資料，則需要使用後端資料庫。但唯讀 Application 資料在 Web 領域中仍然有用。
如果只是為了增加正常已耗用時間（用於處理容錯移轉和伺服器維護），大多數執行重要任務的網站將需要部署至少兩台 Web 服務器。所以，在設計執行重要任務的應用程式時，您將需要實施“粘性會話”，或者簡單地避開 Sessions 以及其他任何在單個 Web 服務器上儲存使用者狀態的狀態管理技術。
如果當前沒有使用 Sessions，請確保將它們關閉。可以通過“網際網路服務管理員”（請參閱 ISM 文檔）來為應用程式執行該操作。如果決定使用 Sessions，可以採取幾個方法來將對效能的影響降低到最小。
可以將不需要 Sessions 的內容（如“協助”螢幕、訪問者地區等）移動到關閉了 Sessions 的、單獨的 ASP 應用程式中。可以逐頁提示 ASP：在給定的頁中您不需要 Session 對象；使用位於 ASP 頁頂端的如下指令：
<% @EnableSessionState=False %>
使用該指令的一個很好的原因是，Session 給框架組帶來了有趣的問題。ASP 保證任何時候只執行一個來自 Session 的請求。這樣可以確保如果瀏覽器為一個使用者請求了多個頁時，在每一時刻只有一個 ASP 請求將進入 Session；這就避免了在訪問 Session 對象時出現多線程問題。遺憾的是，結果，框架組中的所有頁均被以序列化方式繪製，一個接一個地，而不是同時地。這樣，使用者可能不得不等待很長時間才能得到所有架構內容。這意味著：如果某些架構頁不信任 Session，一定要使用 @EnableSessionState=False 指令告訴 ASP。
作為使用 Session 對象的替代方式，有很多方法可以用來管理 Session 狀態。對於狀態數量較小的情況（不到 4 KB），通常建議使用 Cookies、QueryString 變數和隱藏形式的變數。對於較大數量的資料，如購物推車，則使用後端資料庫是最合適的選擇。關於在 Web 服務器領域中的狀態管理技術已經有很多資料。詳細資料，請參閱 工作階段狀態（英文）。
技巧 7：在 COM 物件中封裝代碼 如果您有很多 VBScript 或 JScript，那麼您可以通過把代碼移動到已編譯的 COM 物件來經常改進它們的效能。已編譯的代碼通常比被解釋代碼運行得更快。已編譯的 COM 物件可以通過“早期繫結”訪問其他 COM 物件，這種調用 COM 物件方法的手段，比指令碼所使用的“後期綁定”更有效。
將代碼封裝在 COM 物件種有如下好處（超越效能）：
COM 物件是將表達邏輯與商務邏輯分隔開來的好辦法。
COM 物件啟用了代碼重用。
很多開發商發現，用 VB、C++ 或 Visual J++ 書寫的代碼，比 ASP 更容易調試。
COM 物件有一些缺點，包括初始開發時間以及需要不同的編程技巧。需要警告您的是，封裝“少”量的 ASP 可能會導致效能降低，而不是提高。通常，在少量 ASP 代碼封裝到 COM 物件時出現這樣的情況。這時候，建立和調用 COM 物件的開銷，超過了已編譯代碼的好處。至於 ASP 指令碼和 COM 物件代碼怎樣合并才能產生最佳效能還有待測試。注意，與 Windows NT(R) 4.0/IIS 4.0 相比，Microsoft 已經在 Windows 2000/IIS 5.0 中極大地提高了指令碼和 ADO 效能。這樣，已編譯代碼對 ASP 代碼的效能優勢已經隨著 IIS 5.0 的引入而降低。
有關在 ASP 中使用 COM 物件的優缺點的更多討論，請參閱 ASP 組件準則和用 COM 和 Microsoft Visual Basic 6.0 對分布式應用程式進行編程（英文）。如果您的確部署了 COM 組件，要對它們進行強度測試是非常重要的。實際上，所有 ASP 應用程式都應當作為正式過程進行強度測試。
