技巧 16：如果頁面需要很長時間才能完成，那么執(zhí)行前使用 Response.IsClientConnected
如果用戶性急，他們可能會在您開始執(zhí)行他們的請求之前，就會放棄 ASP 頁面。如果他們單擊刷新或移到服務器上的另一個頁面，在 ASP 請求隊列的末尾就有一個新的請求等候，在隊列的中間有一個斷開連接的請求。當服務器的負載很高時（因此請求隊列就會很長，響應時間也會相應地變長），就會經常發(fā)生這種情況，這樣只能使情況變得更糟。如果用戶不再連接，執(zhí)行 ASP 頁面（特別是慢的、大的 ASP 頁面）已沒有任何意義。您可以使用 Response.IsClientConnected 屬性檢查這一情況。如果它返回 False，則應調用 Response.End 并放棄頁的其余部分。事實上，IIS 5.0 已將這一做法編為程序 - 每當 ASP 即將執(zhí)行新請求時，它就會檢查請求在隊列中已等候了多長時間。如果已經在那里等候了多于 3 秒鐘，ASP 將檢查客戶機是否仍處于連接狀態(tài)，如果沒有連接，就立即終止請求。您可以在配置數據庫中使用 AspQueueConnectionTestTime 設置將超時時間由 3 秒調整為其它值。

如果頁面要花很長時間才能執(zhí)行完，也可以不時地檢查 Response.IsClientConnected。當啟用了響應緩沖時，最好不時地執(zhí)行 Response.Flush，以用戶知道，正在發(fā)生什么事。

注意 在 IIS 4.0 上，除非先執(zhí)行了 Response.Write，否則 Response.IsClientConnected 就不能正常工作。如果啟用了緩沖，您也必須執(zhí)行 Response.Flush。在 IIS 5.0 上，卻沒有必要這樣做，- Response.IsClientConnected 工作正常。在任何情況下，Response.IsClientConnected 都會有一些開銷，因此只有在一個操作至少要花（比方說） 500 毫秒（如果您想維持每秒鐘數十頁的吞吐量，這是一個很長的時間）才使用它。經驗表明，不要每次重復執(zhí)行緊密循環(huán)時都調用它，如顯示表的許多行時 - 每隔二十或五十行調用一次可能比較合適。

技巧 17：使用 <OBJECT> 標記例示對象
如果要引用不在所有代碼路徑（特別是服務器或應用程序作用域的對象）中使用的對象，使用 Global.asa 中 <object runat=server id=objname> 標記聲明它們，而不使用 Server.CreateObject 方法。Server.CreateObject 能立即創(chuàng)建對象。如果以后不再使用該對象，您就浪費了資源。<object id=objname> 標記聲明 objname，但在其方法或屬性第一次使用以前，不會創(chuàng)建 objname。

這又是一個惰性計算的例子。

技巧 18：對于 ADO 和其它組件使用 TypeLib 聲明
當使用 ADO 時，開發(fā)人員經常加入 adovbs.txt，以訪問 ADO 的各種常量。在要使用常量的每個頁面中必須包含此文件。此常量文件相當大，給每個 ASP 頁面的編譯時間和腳本大小增加了許多系統(tǒng)開銷。

IIS 5.0 引入了綁定到組件類型庫的功能。這可使您引用類型庫一次，并將其用在每個 ASP 頁面上。每個頁面不會產生編譯常量文件的開銷，且組件開發(fā)人員不必建立 VBScript#_include 文件以在 ASP 上使用。

要訪問 ADO TypeLib，將下面一條語句放在 Global.asa 中。

<!-- METADATA NAME=?Microsoft ActiveX Data Objects 2.5 Library?
TYPE=?TypeLib? UUID=?{00000205-0000-0010-8000-00AA006D2EA4}? -->


或

<!-- METADATA TYPE=?TypeLib?
FILE=?C:\Program Files\Common Files\system\ado\msado15.dll? -->


技巧 19: 利用瀏覽器的驗證功能
現今的瀏覽器對一些高級功能如 XML、DHTML、Java 小程序和遠程數據服務提供支持。盡可能使用這些功能。所有這些技術都可以執(zhí)行客戶機端驗證和數據緩存，免去了到 Web 服務器的往返。如果您在運行一個智能瀏覽器，那么瀏覽器就能為您進行一些驗證（例如，在執(zhí)行 POST 之前，檢查信用卡校驗和是否有效）。盡可能使用這一功能。通過減少客戶-服務器之間的往返，可降低 Web 服務器上的負載，并能減少網絡通信量（雖然發(fā)送到瀏覽器的第一個頁面可能比較大）以及服務器訪問的任何后端資源。此外，用戶不必像住常一樣讀取新頁，從而用戶的感覺會好一些。這樣做并不意味著您可以不進行服務器端驗證 - 您還應始終進行服務器端驗證。這可以防止由于某種原因（如黑客，或瀏覽器不運行客戶機端驗證例程）客戶機產生錯誤的數據。

人們已經進行了大量的工作，開發(fā)“獨立于瀏覽器”的 HTML。正是由于這種憂慮，開發(fā)人員不愿再使用流行的瀏覽器功能，但這些功能本可以改善性能。對于一些真正的高性能站點，必須關心瀏覽器“訪問”問題，一個好的策略是優(yōu)化頁面，使其適應流行的瀏覽器。使用瀏覽器功能組件，可以在 ASP 中方便地檢測到瀏覽器功能。Microsoft FrontPage 等工具有助于設計適合于瀏覽器和指定 HTML 版本的代碼。參見 When is Better Worse？Weighing the Technology Trade-Offs，以了解更進一步的討論。