改進(jìn)性能和樣式的 25+ ASP 技巧(3)

2019-11-18 20:57:29

字體：大中小

供稿：網(wǎng)友

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

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

下面代碼展示了您沒有必要地使用了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 數(shù)組為正確的大小（本例中為 5），而不是 Redim 數(shù)組，再加大數(shù)組。這可能會浪費(fèi)一點兒內(nèi)存（如果沒有用盡所有元素），但是獲得的是速度。

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

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

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

<% Response.Buffer = True %>

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

Response.Flush

響應(yīng)緩沖的通病是用戶感覺 ASP 頁響應(yīng)遲鈍（盡管總體響應(yīng)時間改善了），因為他們需要等到整個頁生成后才能看見該頁。對于長時間運(yùn)行的頁面，可以通過設(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ù)給了您兩個舉世無雙的好東西 - 響應(yīng)緩沖與瀏覽器中數(shù)據(jù)的逐步顯示的組合。

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

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

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

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

下面是更有效的代碼，每行中有一個對響應(yīng)流的寫入。所有代碼均包含在一個 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)緩沖被禁用時，本技巧的作用更大。最好啟用響應(yīng)緩沖，然后觀察批處理 Response.Write 是否對性能有幫助。

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

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

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

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

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

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

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

這是遲緩計算的另一個例子。

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

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

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

要訪問 ADO 類型庫，請將下列語句之一放入 Global.asa 中。



或者



技巧 19：利用瀏覽器的驗證能力

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

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

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

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

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

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

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

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

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

上一篇：改進(jìn)性能和樣式的 25+ ASP 技巧(4)

下一篇：改進(jìn)性能和樣式的 25+ ASP 技巧(2)