技巧 13：避免重新定義數(shù)組

盡量避免 Redim 數(shù)組。從關(guān)心性能的角度來(lái)說，如果計(jì)算機(jī)受物理內(nèi)存的限制，最好一開始將數(shù)組的維數(shù)設(shè)置為最差方案 - 而不要將維數(shù)設(shè)置為最佳方案，再根據(jù)需要重新定義維數(shù)。這并不意味著明知道不需要那么多而就是應(yīng)該分配太多的內(nèi)存。

下面代碼展示了您沒有必要地使用了Dim 和 Redim 來(lái)解決。

<%
Dim MyArray()
Redim MyArray(2)
MyArray(0) = "hello"
MyArray(1) = "good-bye"
MyArray(2) = "farewell"
...
' 一些別的代碼中，這里您不需要更多的空間，然后 ...
Redim Preserve MyArray(5)
MyArray(3) = "more stuff"
MyArray(4) = "even more stuff"
MyArray(5) = "yet more stuff"
%>

更好的辦法是只須一開始 Dim 數(shù)組為正確的大小（本例中為 5），而不是 Redim 數(shù)組，再加大數(shù)組。這可能會(huì)浪費(fèi)一點(diǎn)兒內(nèi)存（如果沒有用盡所有元素），但是獲得的是速度。

技巧 14：使用響應(yīng)緩沖

您可以通過打開“響應(yīng)緩沖區(qū)”來(lái)緩沖值得輸出的整個(gè)頁(yè)。這將寫入瀏覽器的數(shù)據(jù)量降為最小，從而提高總體性能。每次寫入都會(huì)有大量開銷（包括 IIS 和通過電纜發(fā)送的數(shù)據(jù)量），因此寫入的越少越好。TCP/IP 的工作效率，在發(fā)送少量大的數(shù)據(jù)塊時(shí)明顯高于發(fā)送大量小的數(shù)據(jù)塊時(shí)，原因在于它的低速啟動(dòng)和 Nagling 算法（用于最小化網(wǎng)絡(luò)阻塞）。

打開響應(yīng)緩沖有兩種方法。第一種，可以使用“Internet 服務(wù)管理器”為整個(gè)應(yīng)用程序打開響應(yīng)緩沖。這是推薦的方法，在 IIS 4.0 和 IIS 5.0 中，在默認(rèn)情況下，為新的 ASP 應(yīng)用程序打開響應(yīng)緩沖。第二種，逐頁(yè)將下列代碼行放在 ASP 頁(yè)的開頭，從而啟用響應(yīng)緩沖：

<% Response.Buffer = True %>

該行代碼必須在任何響應(yīng)數(shù)據(jù)寫入瀏覽器之前執(zhí)行（也就是說，在任何 HTML 出現(xiàn)在 ASP 腳本中之前和任何 Cookies 被使用 Response.Cookies 集合設(shè)置之前）。通常，最好是為整個(gè)應(yīng)用程序打開響應(yīng)緩沖。這允許省略上面每頁(yè)中的代碼行。

Response.Flush

響應(yīng)緩沖的通病是用戶感覺 ASP 頁(yè)響應(yīng)遲鈍（盡管總體響應(yīng)時(shí)間改善了），因?yàn)樗麄冃枰�等到整個(gè)頁(yè)生成后才能看見該頁(yè)。對(duì)于長(zhǎng)時(shí)間運(yùn)行的頁(yè)面，可以通過設(shè)置 Response.Buffer = False 關(guān)閉響應(yīng)緩沖。但是，更好的策略是使用 Response.Flush 方法。該方法刷新由 ASP 繪入瀏覽器的所有 HTML。例如，繪制了具有 1,000 行的表的 100 行后，ASP 可以調(diào)用 Response.Flush 強(qiáng)制將結(jié)果繪制到瀏覽器；這允許用戶在其余的行準(zhǔn)備好之前先看到頭 100 行。該技術(shù)給了您兩個(gè)舉世無(wú)雙的好東西 - 響應(yīng)緩沖與瀏覽器中數(shù)據(jù)的逐步顯示的組合。

（注意，在上面 1,000 行表的示例中，許多瀏覽器，在看到 </table> 結(jié)束標(biāo)記之前不會(huì)開始繪制表。請(qǐng)檢查目標(biāo)瀏覽器的支持性。要解決該問題，請(qǐng)將表分割為具有較少行的多個(gè)表，然后在每個(gè)表后面調(diào)用 Response.Flush。新版本的 Internet Explorer 將在表完全下載之前繪制表，特別是如果指定表的列寬則繪制速度更快；這避免強(qiáng)制 Internet Explorer 通過度量每個(gè)單元格的內(nèi)容來(lái)計(jì)算列寬。）

響應(yīng)緩沖的另一個(gè)通病是在生成大型頁(yè)時(shí)將使用服務(wù)器的大量?jī)?nèi)存。對(duì)于該問題，除了要求生成大型頁(yè)的技巧外，還可以通過巧妙地使用 Response.Flush 來(lái)解決。

技巧 15：批處理內(nèi)嵌腳本和 Response.Write 語(yǔ)句

VBScript 語(yǔ)法 <% = expression %> 將“表達(dá)式”的值寫入 ASP 輸出流。如果響應(yīng)緩沖沒有打開，則這些語(yǔ)句的每一句都會(huì)導(dǎo)致通過網(wǎng)絡(luò)，以許多小型包的形式，向?yàn)g覽器寫入數(shù)據(jù)。這是非常慢的。另外，解釋少量腳本和 HTML，將導(dǎo)致在腳本引擎和 HTML 之間切換，也降低了性能。因此，請(qǐng)使用下面技巧：用對(duì) Response.Write 的一個(gè)調(diào)用，替換內(nèi)嵌的密集組合表達(dá)式。例如，在下面范例中，每行每字段有一個(gè)對(duì)響應(yīng)流的寫入，每行都有許多 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>

下面是更有效的代碼，每行中有一個(gè)對(duì)響應(yīng)流的寫入。所有代碼均包含在一個(gè) VBScript 塊內(nèi)：

<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>

當(dāng)響應(yīng)緩沖被禁用時(shí)，本技巧的作用更大。最好啟用響應(yīng)緩沖，然后觀察批處理 Response.Write 是否對(duì)性能有幫助。

（在這一特例中，構(gòu)建表的主體的嵌套循環(huán) (While Not rs.EOF...) 可以被精心構(gòu)造的、對(duì) GetString 的調(diào)用所替代。）

技巧 16：在開始長(zhǎng)時(shí)間的任務(wù)之前先使用 Response.IsClientConnected

如果用戶失去耐心，他們可以在開始執(zhí)行他們的請(qǐng)求之前放棄 ASP 頁(yè)。如果他們單擊了 Refresh 或跳轉(zhuǎn)到服務(wù)器的其他頁(yè)上，在 ASP 請(qǐng)求隊(duì)列的末尾將有一個(gè)新的請(qǐng)求，而在隊(duì)列的中間有一個(gè)斷開連接的請(qǐng)求。這通常發(fā)生在服務(wù)器處于高負(fù)荷的情況下（它有一個(gè)很長(zhǎng)的請(qǐng)求隊(duì)列，相應(yīng)的響應(yīng)時(shí)間也很長(zhǎng)），這只能使情況更糟。如果用戶不再連接，將沒有執(zhí)行 ASP 頁(yè)的點(diǎn)（特別是低速、重量級(jí)的 ASP 頁(yè)）。可以使用 Response.IsClientConnected 屬性檢查這種情況。如果它返回 False，則應(yīng)調(diào)用 Response.End 并放棄該頁(yè)的剩余內(nèi)容。實(shí)際上，每當(dāng) ASP 要執(zhí)行新的請(qǐng)求時(shí)，IIS 5.0 便將該方法編碼，來(lái)檢查隊(duì)列中的請(qǐng)求有多長(zhǎng)。如果在那里超過了 3 秒鐘，ASP 會(huì)檢查客戶是否仍然連接著，如果客戶已斷開連接，就立即結(jié)束該請(qǐng)求。您可以使用 metabase 中的 AspQueueConnectionTestTime 設(shè)置，調(diào)整這 3 秒的超時(shí)時(shí)間。

如果有某頁(yè)執(zhí)行了很長(zhǎng)時(shí)間，您可能還想按一定的時(shí)間間隔檢查 Response.IsClientConnected。在啟用響應(yīng)緩沖之后，按一定的時(shí)間間隔執(zhí)行 Response.Flush，告訴用戶正在進(jìn)行的是哪些事情，是個(gè)好辦法。

注意 在 IIS 4.0 中，Response.IsClientConnected 將不能正常工作，除非首先執(zhí)行 Response.Write。如果啟用了緩沖，也需要執(zhí)行 Response.Flush。在 IIS 5.0 中則不必如此 - Response.IsClientConnected 工作得很好。在任何情況下，Response.IsClientConnected 都要有些開銷，所以，只有在執(zhí)行至少要用 500 毫秒（如果想維持每秒幾十頁(yè)的吞吐量，這是一個(gè)很長(zhǎng)的時(shí)間了）的操作前才使用它。作為通常的規(guī)則，不要在緊密循環(huán)的每次迭代中調(diào)用它，例如當(dāng)繪制表中的行，可能每 20 行或每 50 行調(diào)用一次。

技巧 17：使用 <OBJECT> 標(biāo)記實(shí)例化對(duì)象

如果需要引用不能在所有代碼路徑中使用的對(duì)象（尤其是服務(wù)器 - 或應(yīng)用程序 - 作用域的對(duì)象），則使用 Global.asa 中的 <object runat=server id=objname> 標(biāo)記來(lái)聲明它們，而不是使用 Server.CreateObject 方法。Server.CreateObject 立刻創(chuàng)建對(duì)象。如果以后不使用那個(gè)對(duì)象，就不要浪費(fèi)資源。<object id=objname> 標(biāo)記聲明了 objname，但實(shí)際上 objname 此時(shí)并沒有創(chuàng)建，直到它的方法或?qū)傩缘谝淮伪皇褂脮r(shí)才創(chuàng)建。

這是遲緩計(jì)算的另一個(gè)例子。

技巧 18：使用 ADO 對(duì)象和其他組件的 TypeLib 聲明

當(dāng)使用 ADO 時(shí)，開發(fā)人員經(jīng)常包含 adovbs.txt 來(lái)獲得對(duì) ADO 不同常量的訪問權(quán)。該文件必須包含在要使用這些常量的每一頁(yè)中。該常量文件非常大，給每個(gè) ASP 頁(yè)增加了很多編譯時(shí)間和腳本大小方面的開銷。

IIS 5.0 提供了綁定到組件類型庫(kù)的能力。允許您在每個(gè) ASP 頁(yè)上引用一次類型庫(kù)并使用它。每頁(yè)不需要為編譯常量文件付出代價(jià)，并且組件開發(fā)人員不必為在 ASP 中的使用而生成 VBScript #include 文件。

要訪問 ADO 類型庫(kù)，請(qǐng)將下列語(yǔ)句之一放入 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：利用瀏覽器的驗(yàn)證能力

流行的瀏覽器具有對(duì)以下功能的高級(jí)支持，例如 XML、DHTML、Java 小程序以及遠(yuǎn)程數(shù)據(jù)服務(wù)。請(qǐng)盡量利用這些功能。所有這些技術(shù)，都可以通過執(zhí)行客戶端的驗(yàn)證和數(shù)據(jù)緩存，減少了與 Web 服務(wù)器之間的往返。如果您正在運(yùn)行智能瀏覽器，該瀏覽器可以為您進(jìn)行一些驗(yàn)證（例如，在運(yùn)行 POST 之前檢查信用卡的校驗(yàn)和否有效）。重申一次，請(qǐng)盡量使用這些功能。由于削減了客戶端到服務(wù)器的往返路程，將減少對(duì) Web 服務(wù)器的壓力，并且削減了網(wǎng)絡(luò)通信量（雖然發(fā)送給瀏覽器的初始頁(yè)面可能更大），服務(wù)器訪問的所有后端資源也削減了。而且用戶不必經(jīng)常提取新頁(yè)，使用戶的感受好一些。這并不減輕對(duì)服務(wù)器端驗(yàn)證的需要。還是應(yīng)該經(jīng)常進(jìn)行服務(wù)器端的驗(yàn)證。這樣能夠防止由于某些原因從客戶端來(lái)的壞數(shù)據(jù)，例如黑客，或者不運(yùn)行客戶端驗(yàn)證程序的瀏覽器。

許多站點(diǎn)由獨(dú)立于瀏覽器創(chuàng)建的 HTML 組成。這一點(diǎn)經(jīng)常阻礙開發(fā)人員利用可以提高性能的流行瀏覽器功能。對(duì)于真正高性能的、必須關(guān)心瀏覽器的站點(diǎn)，良好的策略是針對(duì)流行的瀏覽器優(yōu)化您的頁(yè)面。在 ASP 中使用“瀏覽器性能組件”，很容易檢測(cè)到瀏覽器的功能。諸如 Microsoft FrontPage 等工具，能幫助您設(shè)計(jì)使用所希望的目標(biāo)瀏覽器和 HTML 版本的代碼。更詳細(xì)的討論，請(qǐng)查看 When is Better Worse? Weighing the Technology Trade-Offs（英文）。

技巧 20：在循環(huán)中避免字符串串聯(lián)

許多人在循環(huán)中創(chuàng)建類似這樣的字符串：

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

這種方法有幾個(gè)問題。首先，重復(fù)連接字符串所花費(fèi)的時(shí)間，以二次方曲線的速率增長(zhǎng)；粗略地計(jì)算，運(yùn)行循環(huán)所花費(fèi)的時(shí)間，與記錄數(shù)乘以字段數(shù)的平方成正比。舉一個(gè)簡(jiǎn)單的例子，便能清楚地說明這一點(diǎn)。

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

在第一次迭代中，得到一個(gè)字符的字符串“A”。在第二次迭代中，VBScript 必須重新分配字符串并復(fù)制兩個(gè)字符“AB”到 s。在第三次迭代中，它必須再次重新分配 s，并復(fù)制三個(gè)字符到 s。在第 N 次（26 次）迭代中，它必須重新分配并復(fù)制 N 個(gè)字符到 s。就是 1+2+3+...+N 的和，為 N*(N+1)/2 次復(fù)制。

在以上記錄集的例子中，如果有 100 條記錄和 5個(gè)字段，則內(nèi)部的循環(huán)將執(zhí)行 100*5 = 500 次，并且完成所有復(fù)制和重新分配所花費(fèi)時(shí)間，將與 500*500 = 250,000 成正比。對(duì)一個(gè)大小適度的記錄集，將有很多次復(fù)制。

在該例子中，代碼可以改進(jìn)：字符串的連接將被 Response.Write() 或內(nèi)嵌腳本 (<% = fld.Value %>) 所替代。如果打開響應(yīng)緩沖，這個(gè)操作將會(huì)很快，因?yàn)?Response.Write 僅僅將數(shù)據(jù)添加到響應(yīng)緩沖的末尾。不再重新分配，因而非常有效。

特別是在將 ADO 記錄集轉(zhuǎn)換到 HTML 表時(shí)，請(qǐng)考慮使用 GetRows 或 GetString。

如果用 JScript 連接字符串，強(qiáng)烈建議使用 += 操作符；即用 s += "某字符串"， 而不是 s = s + "某字符串"。