|
技巧 13：避免重新定義數組
盡量避免 Redim 數組。從關心性能的角度來說，如果計算機受物理內存的限制，最好一開始將數組的維數設置為最差方案 - 而不要將維數設置為最佳方案，再根據需要重新定義維數。這并不意味著明知道不需要那么多而就是應該分配太多的內存。
下面代碼展示了您沒有必要地使用了Dim 和 Redim 來解決。
<%
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 數組為正確的大小（本例中為 5），而不是 Redim 數組，再加大數組。這可能會浪費一點兒內存（如果沒有用盡所有元素），但是獲得的是速度。
技巧 14：使用響應緩沖
您可以通過打開“響應緩沖區”來緩沖值得輸出的整個頁。這將寫入瀏覽器的數據量降為最小，從而提高總體性能。每次寫入都會有大量開銷（包括 IIS 和通過電纜發送的數據量），因此寫入的越少越好。TCP/IP 的工作效率，在發送少量大的數據塊時明顯高于發送大量小的數據塊時，原因在于它的低速啟動和 Nagling 算法（用于最小化網絡阻塞）。
打開響應緩沖有兩種方法。第一種，可以使用“Internet 服務管理器”為整個應用程序打開響應緩沖。這是推薦的方法，在 IIS 4.0 和 IIS 5.0 中，在默認情況下，為新的 ASP 應用程序打開響應緩沖。第二種，逐頁將下列代碼行放在 ASP 頁的開頭，從而啟用響應緩沖：
<% Response.Buffer = True %>
該行代碼必須在任何響應數據寫入瀏覽器之前執行（也就是說，在任何 HTML 出現在 ASP 腳本中之前和任何 Cookies 被使用 Response.Cookies 集合設置之前）。通常，最好是為整個應用程序打開響應緩沖。這允許省略上面每頁中的代碼行。
Response.Flush
響應緩沖的通病是用戶感覺 ASP 頁響應遲鈍（盡管總體響應時間改善了），因為他們需要等到整個頁生成后才能看見該頁。對于長時間運行的頁面，可以通過設置 Response.Buffer = False 關閉響應緩沖。但是，更好的策略是使用 Response.Flush 方法。該方法刷新由 ASP 繪入瀏覽器的所有 HTML。例如，繪制了具有 1,000 行的表的 100 行后，ASP 可以調用 Response.Flush 強制將結果繪制到瀏覽器；這允許用戶在其余的行準備好之前先看到頭 100 行。該技術給了您兩個舉世無雙的好東西 - 響應緩沖與瀏覽器中數據的逐步顯示的組合。
（注意，在上面 1,000 行表的示例中，許多瀏覽器，在看到 </table> 結束標記之前不會開始繪制表。請檢查目標瀏覽器的支持性。要解決該問題，請將表分割為具有較少行的多個表，然后在每個表后面調用 Response.Flush。新版本的 Internet Explorer 將在表完全下載之前繪制表，特別是如果指定表的列寬則繪制速度更快；這避免強制 Internet Explorer 通過度量每個單元格的內容來計算列寬。）
響應緩沖的另一個通病是在生成大型頁時將使用服務器的大量內存。對于該問題，除了要求生成大型頁的技巧外，還可以通過巧妙地使用 Response.Flush 來解決。
技巧 15：批處理內嵌腳本和 Response.Write 語句
VBScript 語法 <% = 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 頁。如果他們單擊了 Refresh 或跳轉到服務器的其他頁上，在 ASP 請求隊列的末尾將有一個新的請求，而在隊列的中間有一個斷開連接的請求。這通常發生在服務器處于高負荷的情況下（它有一個很長的請求隊列，相應的響應時間也很長），這只能使情況更糟。如果用戶不再連接，將沒有執行 ASP 頁的點（特別是低速、重量級的 ASP 頁）。可以使用 Response.IsClientConnected 屬性檢查這種情況。如果它返回 False，則應調用 Response.End 并放棄該頁的剩余內容。實際上，每當 ASP 要執行新的請求時，IIS 5.0 便將該方法編碼，來檢查隊列中的請求有多長。如果在那里超過了 3 秒鐘，ASP 會檢查客戶是否仍然連接著，如果客戶已斷開連接，就立即結束該請求。您可以使用 metabase 中的 AspQueueConnectionTestTime 設置，調整這 3 秒的超時時間。
如果有某頁執行了很長時間，您可能還想按一定的時間間隔檢查 Response.IsClientConnected。在啟用響應緩沖之后，按一定的時間間隔執行 Response.Flush，告訴用戶正在進行的是哪些事情，是個好辦法。
注意 在 IIS 4.0 中，Response.IsClientConnected 將不能正常工作，除非首先執行 Response.Write。如果啟用了緩沖，也需要執行 Response.Flush。在 IIS 5.0 中則不必如此 - Response.IsClientConnected 工作得很好。在任何情況下，Response.IsClientConnected 都要有些開銷，所以，只有在執行至少要用 500 毫秒（如果想維持每秒幾十頁的吞吐量，這是一個很長的時間了）的操作前才使用它。作為通常的規則，不要在緊密循環的每次迭代中調用它，例如當繪制表中的行，可能每 20 行或每 50 行調用一次。
技巧 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 頁上引用一次類型庫并使用它。每頁不需要為編譯常量文件付出代價，并且組件開發人員不必為在 ASP 中的使用而生成 VBScript #include 文件。
要訪問 ADO 類型庫，請將下列語句之一放入 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 + "某字符串"。
|
