改進(jìn)性能與樣式的 25+ ASP 技巧(3)
發(fā)表時間:2023-08-08 來源:明輝站整理相關(guān)軟件相關(guān)文章人氣:4
[摘要]技巧 13:避免重新定義數(shù)組 盡量避免 Redim 數(shù)組。從關(guān)心性能的角度來說,如果計(jì)算機(jī)受物理內(nèi)存的限制,最好一開始將數(shù)組的維數(shù)設(shè)置為最差方案 - 而不要將維數(shù)設(shè)置為最佳方案,再根據(jù)需要重新定義維...
技巧 13:避免重新定義數(shù)組
盡量避免 Redim 數(shù)組。從關(guān)心性能的角度來說,如果計(jì)算機(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)一點(diǎn)兒內(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)樗麄冃枰鹊秸麄€頁生成后才能看見該頁。對于長時間運(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)容來計(jì)算列寬。)
響應(yīng)緩沖的另一個通病是在生成大型頁時將使用服務(wù)器的大量內(nèi)存。對于該問題,除了要求生成大型頁的技巧外,還可以通過巧妙地使用 Response.Flush 來解決。
技巧 15:批處理內(nèi)嵌腳本和 Response.Write 語句
VBScript 語法 <% = expression %> 將“表達(dá)式”的值寫入 ASP 輸出流。如果響應(yīng)緩沖沒有打開,則這些語句的每一句都會導(dǎo)致通過網(wǎng)絡(luò),以許多小型包的形式,向?yàn)g覽器寫入數(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 請求隊(duì)列的末尾將有一個新的請求,而在隊(duì)列的中間有一個斷開連接的請求。這通常發(fā)生在服務(wù)器處于高負(fù)荷的情況下(它有一個很長的請求隊(duì)列,相應(yīng)的響應(yīng)時間也很長),這只能使情況更糟。如果用戶不再連接,將沒有執(zhí)行 ASP 頁的點(diǎn)(特別是低速、重量級的 ASP 頁)。可以使用 Response.IsClientConnected 屬性檢查這種情況。如果它返回 False,則應(yīng)調(diào)用 Response.End 并放棄該頁的剩余內(nèi)容。實(shí)際上,每當(dāng) ASP 要執(zhí)行新的請求時,IIS 5.0 便將該方法編碼,來檢查隊(duì)列中的請求有多長。如果在那里超過了 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)記實(shí)例化對象
如果需要引用不能在所有代碼路徑中使用的對象(尤其是服務(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,但實(shí)際上 objname 此時并沒有創(chuàng)建,直到它的方法或?qū)傩缘谝淮伪皇褂脮r才創(chuàng)建。
這是遲緩計(jì)算的另一個例子。
技巧 18:使用 ADO 對象和其他組件的 TypeLib 聲明
當(dāng)使用 ADO 時,開發(fā)人員經(jīng)常包含 adovbs.txt 來獲得對 ADO 不同常量的訪問權(quán)。該文件必須包含在要使用這些常量的每一頁中。該常量文件非常大,給每個 ASP 頁增加了很多編譯時間和腳本大小方面的開銷。
IIS 5.0 提供了綁定到組件類型庫的能力。允許您在每個 ASP 頁上引用一次類型庫并使用它。每頁不需要為編譯常量文件付出代價(jià),并且組件開發(fā)人員不必為在 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:利用瀏覽器的驗(yàn)證能力
流行的瀏覽器具有對以下功能的高級支持,例如 XML、DHTML、Java 小程序以及遠(yuǎn)程數(shù)據(jù)服務(wù)。請盡量利用這些功能。所有這些技術(shù),都可以通過執(zhí)行客戶端的驗(yàn)證和數(shù)據(jù)緩存,減少了與 Web 服務(wù)器之間的往返。如果您正在運(yùn)行智能瀏覽器,該瀏覽器可以為您進(jìn)行一些驗(yàn)證(例如,在運(yùn)行 POST 之前檢查信用卡的校驗(yàn)和否有效)。重申一次,請盡量使用這些功能。由于削減了客戶端到服務(wù)器的往返路程,將減少對 Web 服務(wù)器的壓力,并且削減了網(wǎng)絡(luò)通信量(雖然發(fā)送給瀏覽器的初始頁面可能更大),服務(wù)器訪問的所有后端資源也削減了。而且用戶不必經(jīng)常提取新頁,使用戶的感受好一些。這并不減輕對服務(wù)器端驗(yàn)證的需要。還是應(yīng)該經(jīng)常進(jìn)行服務(wù)器端的驗(yàn)證。這樣能夠防止由于某些原因從客戶端來的壞數(shù)據(jù),例如黑客,或者不運(yùn)行客戶端驗(yàn)證程序的瀏覽器。
許多站點(diǎn)由獨(dú)立于瀏覽器創(chuàng)建的 HTML 組成。這一點(diǎn)經(jīng)常阻礙開發(fā)人員利用可以提高性能的流行瀏覽器功能。對于真正高性能的、必須關(guān)心瀏覽器的站點(diǎn),良好的策略是針對流行的瀏覽器優(yōu)化您的頁面。在 ASP 中使用“瀏覽器性能組件”,很容易檢測到瀏覽器的功能。諸如 Microsoft FrontPage 等工具,能幫助您設(shè)計(jì)使用所希望的目標(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)的時間,以二次方曲線的速率增長;粗略地計(jì)算,運(yùn)行循環(huán)所花費(fèi)的時間,與記錄數(shù)乘以字段數(shù)的平方成正比。舉一個簡單的例子,便能清楚地說明這一點(diǎn)。
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)緩沖,這個操作將會很快,因?yàn)?Response.Write 僅僅將數(shù)據(jù)添加到響應(yīng)緩沖的末尾。不再重新分配,因而非常有效。
特別是在將 ADO 記錄集轉(zhuǎn)換到 HTML 表時,請考慮使用 GetRows 或 GetString。
如果用 JScript 連接字符串,強(qiáng)烈建議使用 += 操作符;即用 s += "某字符串", 而不是 s = s + "某字符串"。