技巧 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 + "某字符串"。
|