技巧 15：批處理內嵌腳本和 Response.Write 語句
技巧 16：如果頁面需要很長時間才能完成，那么執行前使用 Response.IsClientConnected
技巧 17：使用 <OBJECT> 標記例示對象
技巧 18：對于 ADO 和其它組件使用 TypeLib 綁定
技巧 19：利用瀏覽器的驗證功能
技巧 20：避免在循環語句中使用字符串串聯
技巧 21：啟用瀏覽器和代理緩存
技巧 15：批處理內嵌腳本和 Response.Write 語句
VBScript 語法 <% = expression %> 將“expression”的值寫到 ASP 輸出流中。如果響應緩沖未啟用，那么執行其中的每一條語句，都會以許多小的數據包通過網絡將數據寫到瀏覽器中。這樣速度很慢。而且穿插執行少量的腳本和 HTML，將引起腳本引擎和 HTML 之間的切換，從而降低性能。因此，使用下面的技巧：使用 Response.Write 調用代替捆綁緊密的內嵌表達式。例如，在下面的示例中，在每一行的每一字段對響應流有一次寫操作，每一行在 VBScript 和 HTML 之間有許多切換：

<table>
<% For Each fld in rs.Fields %>
<th><% = fld.Name %></th>
<%
Next
While Not rs.EOF
%>
<tr>
<% For Each fld in rs.Fields %>
<td><% = fld.Value %></td>
<% Next
</tr>
<% rs.MoveNext
Wend %>
</table>


下面的代碼更有效，每一行對響應流有一次寫操作。所有的代碼都包含在一個 VBScript 塊內：

<table>
<%
For each fld in rs.Fields
Response.Write (?<th>? & fld.Name & ?</th>? & vbCrLf)
Next
While Not rs.EOF
Response.Write (?<tr>?)
For Each fld in rs.Fields %>
Response.Write(?<td>? & fld.Value & ?</td>? & vbCrLf)
Next
Response.Write ?</tr>?
Wend
%>
</table>


當禁用響應緩沖時，這一技巧的效果特別大。最好啟用響應緩沖，然后看批處理 Response.Write 是否有助于提高性能。

（在這一特定舉例中，建立表主體的嵌套循環 (While Not rs.EOF...) 可以用仔細構建的 GetString 調用來替代。）

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

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

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

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

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

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

IIS 5.0 引入了綁定到組件類型庫的功能。這可使您引用類型庫一次，并將其用在每個 ASP 頁面上。每個頁面不會產生編譯常量文件的開銷，且組件開發人員不必建立 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 小程序和遠程數據服務提供支持。盡可能使用這些功能。所有這些技術都可以執行客戶機端驗證和數據緩存，免去了到 Web 服務器的往返。如果您在運行一個智能瀏覽器，那么瀏覽器就能為您進行一些驗證（例如，在執行 POST 之前，檢查信用卡校驗和是否有效）。盡可能使用這一功能。通過減少客戶-服務器之間的往返，可降低 Web 服務器上的負載，并能減少網絡通信量（雖然發送到瀏覽器的第一個頁面可能比較大）以及服務器訪問的任何后端資源。此外，用戶不必像住常一樣讀取新頁，從而用戶的感覺會好一些。這樣做并不意味著您可以不進行服務器端驗證 - 您還應始終進行服務器端驗證。這可以防止由于某種原因（如黑客，或瀏覽器不運行客戶機端驗證例程）客戶機產生錯誤的數據。

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

技巧 20：避免在循環語句中使用字符串串聯
許多人在循環語句中建立一個字符串，如下所示：

s = ?<table>? & vbCrLf
For Each fld in rs.Fields
s = s & ? <th>? & fld.Name & ?</th> ?
Next

While Not rs.EOF
s = s & vbCrLf & ? <tr>?
For Each fld in rs.Fields
s = s & ? <td>? & fld.Value & ?</td> ?
Next
s = s & ? </tr>?
rs.MoveNext
Wend

s = s & vbCrLf & ?</table>? & vbCrLf
Response.Write s


采用這種方法會出現一些問題。第一個問題是反復串聯字符串需要花兩次方的時間，更通俗地說，運行這種循環語句所花的時間與記錄數乘以字段數所得值的平方成正比。舉一個更簡單的例子，就可以更清楚地說明這一問題。

s = ??
For i = Asc(?A?) to Asc(?Z?)
s = s & Chr(i)
Next


在第一次迭代中，您獲得了一個字符的字符串 ?A?。在第二次迭代中，VBScript 必須重新分配字符串并將兩個字符 (?AB?) 復制到 s 中。在第三次迭代中，它還必須再次重新分配 s 并將三個字符復制到 s 中。在 N 次（第 26 次）迭代中，它必須重新分配并將 N 個字符復制到 s 中。總共就是 1+2+3+...+N，即 N*(N+1)/2 次復制。

在上面的記錄集舉例中，如果有 100 個記錄和 5 個字段，內循環將執行 100*5 = 500 次，所有的復制和重新分配所花的時間與 500*500 = 250,000 成正比。這對于中等大小的記錄集來說復制操作太多了。

在本例中，代碼可以用 Response.Write() 或內嵌腳本 (<% = fld.Value %>) 替代字符串串聯來改進。如果啟用了響應緩沖的話（應該的），這樣做就會更快，因為 Response.Write 只將數據附加到響應緩沖的末尾。并不涉及重新分配，因此效率很高。

在將 ADO 記錄集轉換為 HTML 表的特定情況下，應考慮使用 GetRows 或 GetString。

如果在 JScript 中串聯字符串，特別建議使用 += 運算符，即，使用 s += ?某字符串?，而不使用 s = s + ?某字符串?。

技巧 21：啟用瀏覽器和代理緩存
在默認情況下，ASP 禁止在瀏覽器和代理中進行緩存。這是有意義的，因為就實質而言 ASP 頁面是動態的，上面有隨時間不斷變化的潛在信息。如果頁面不要求在每個視圖上進行刷新，您應啟用瀏覽器和代理緩存。這可使瀏覽器和代理在一定的時間內使用頁面的“緩存”副本，您可以控制時間的長短。緩存可以大大減輕服務器上的負載，縮短用戶的等待時間。

哪一種動態頁面可作為要緩存的頁面呢？下面舉一些例子：

天氣預報頁面，在此頁面上，每隔 5 分鐘更新一次天氣預報。
列出新聞條目或新聞稿的主頁，它一天更新兩次。
共同基金業績列表，在此列表中，基本統計信息每隔幾小時更新一次。
注意，在使用瀏覽器或代理緩存的情況下，Web 服務器上記錄的訪問次數減少了。如果您想準確地測量所有頁面視圖或張帖公布，您就不希望使用瀏覽器和代理緩存。

瀏覽器緩存由 HTTP“過期”報頭控制，該報頭由 Web 服務器發送給瀏覽器。ASP 提供兩個簡單的機制發送此報頭。要設置頁面使其過多少分鐘后到期，則應設置 Response.Expires 屬性。下面的例子告訴瀏覽器內容在 10 分鐘內過期：

<% Response.Expires = 10 %>


若將 Response.Expires 設置為負數或 0，則禁用緩存。一定要使用大的負數，如 -1000（略多于一天），以避免服務器和瀏覽器時鐘之間的不匹配。第二個屬性 Response.ExpiresAbsolute 將使您設置內容過期的具體時間：

<% Response.ExpiresAbsolute = #May 31,2001 13:30:15# %>


您可以不使用 Response 對象設置過期時間，而將 <META> 標記寫進 HTML，通常寫在 HTML 文件的 <HEAD> 部分。一些瀏覽器將遵照此指令，而代理則不然。

<META HTTP-EQUIV=?Expires? VALUE=?May 31,2001 13:30:15?>


最后，您可以使用 Response.CacheControl 屬性，指示其內容是否可以讓 HTTP 代理緩存。若將此屬性設置為“Public”，代理就可以緩存此內容。

<% Response.CacheControl = ?Public? %>


在默認情況下，此屬性被設置為“Private”。注意，對于顯示某用戶特定數據的頁面，不應啟用代理緩存，因為代理可能給用戶提供屬于其他用戶的頁面。