|
技巧 7: 將代碼封裝在 COM 對象中如果您有許多 VBScript 或 JScript，您可以經常將代碼移到編譯的 COM 對象中，從而可改善性能。編譯的代碼通常比解釋的代碼運行得更快。編譯的 COM 對象可以通過“早綁定”訪問其它 COM 對象，與腳本使用的“晚綁定”相比，“早綁定”是調用 COM 對象的更有效方法。 將代碼封裝在 COM 對象中還有一些優點（除性能之外）：
COM 對象也有缺點，包括初始開發時間和需要不同的程序設計技巧。注意封裝少量的 ASP 可能引起性能下降，而不會得到性能改進。這種情況通常在少量的 ASP 代碼被封裝進 COM 對象時發生。在這種情況下，創建和調用 COM 對象的系統開銷超過了編譯的代碼的優點。應反復地試驗，以確定什么樣的 ASP 腳本和 COM 對象代碼的組合產生最好的性能。注意，與 Microsoft Windows NT® 4.0/IIS 4.0 相比，Windows 2000/IIS 5.0 中在腳本和 ADO 性能方面有了很大的改進。因此，隨著 IIS 5.0 的推出，編譯代碼比 ASP 代碼的性能優勢有所降低。 有關在 ASP 中使用 COM 的優點和缺點的詳細討論，參見 ASP Component Guidelines and Programming Distributed Applications with and Microsoft Visual Basic 6.0。如果您部署 COM 組件，以負荷對它們進行測試特別重要。事實上，理所當然應對所有的 ASP 應用程序進行負荷測試。 技巧 8：遲一點獲得資源，早一點釋放資源這里是一個小技巧供您參考。一般來說，最好遲一點獲得資源，早一點釋放資源。這適用于 COM 對象以及文件句柄和其它資源。 這種優化方法主要用于 ADO 連接和記錄集。當您使用完記錄集，比方說在顯示一個表及其數據之后，應立即釋放它，而不是等到頁面結束時再釋放。將 VBScript 變量設置為 Nothing 是最好的做法。不要讓記錄集超出作用域之外。而且，要釋放任何相關的 Command 或 Connection 對象（在將記錄集或連接設置為 = Nothing 之前，不要忘記調用 Close()）。這會縮短數據庫必須為您準備資源的時間，并盡快釋放數據庫到連接池的連接。 技巧 9：進程外執行過程以性能換取可靠性ASP 和 MTS/COM+ 兩者都有配置選項，可使您兼顧可靠性和性能。當建立和部署應用程序時，應知道如何兼顧兩者的性能。 ASP 選項可以配置 ASP 應用程序，以便以三種方法之一運行。在 IIS 5.0 中，引入了“隔離級”這一術語以說明這些選項。這三個隔離級分別是低級、中級和高級：
哪個選項最好的呢？在 IIS 4.0 中，進程外運行將顯著降低性能。在 IIS 5.0 中，做了許多改進，將進程外運行 ASP 應用程序所產生的開銷降到最低限度。事實上，在絕大多數測試中，IIS 5.0 中的 ASP 進程外應用程序比 IIS 4.0 中的進程內應用程序運行得更快。不管怎樣，在兩個平臺上，進程內（低隔離級）性能最佳。但是，如果訪問率相對較低或最大吞吐量較低，低隔離級的優勢不太明顯。因此，在您每一 Web 服務器每秒鐘需要數百或成千上萬頁面時，才會覺得有必要設置低隔離級。與往常一樣，應對多種配置進行測試，確定您要采取哪一種折衷方案。 注意 當您運行 ASP 進程外應用程序時（中級或高級隔離），它們在 NT4 中的 MTS 和在 Windows 2000 中的 COM+ 中運行。即，在 NT4 中它們在 Mtx.exe 中運行；而在 Windows 2000 中，它們在 DllHost.exe 中運行。您可以在任務管理器中看到這些進程在運行。您還可以看到 IIS 如何為進程外 ASP 應用程序配置 MTS 程序包或 COM+ 應用程序。 COM 選項COM 組件也有三種配置選項，雖然與 ASP 選項不完全類似。COM 組件可以是“未配置的”、配置為庫應用程序或配置為服務器應用程序。“未配置的”意思是指組件沒有注冊 COM+。組件將在調用程序的進程空間運行，那就是說，它們是“進程內的”。庫應用程序也是進程內的，但使用 COM+ 的服務，包括安全、事務和上下文支持。服務器應用程序被配置為在它們自有的進程空間內運行。 您可以看到未配置的組件比庫應用程序略有一些優勢。庫應用程序比服務器應用程序的性能優點更大。這是因為庫應用程序與 ASP 在同一進程內運行，而服務器應用程序在它們的自有進程內運行。進程間的調用比進程內調用開銷更大。而且，當在進程之間傳遞諸如記錄集之類的數據時，必須在兩個進程之間復制所有的數據。 陷阱！當使用 COM 服務器應用程序時，如果您在 ASP 和 COM 之間傳遞對象，要確保對象執行“按值匯集”或 MBV。執行 MBV 的對象將它們自己從一個進程復制到另一個進程。這比下面一種方法好，采用這種方法時，對象仍在創建者的進程中，另外一個進程反復地調用創建進程以使用該對象。切斷連接的 ADO 記錄集將“按值匯集”，連接的記錄集則不然。Scripting.Dictionary 不執行 MBV，且不在進程之間傳遞。最后，VB 程序員請注意：MBV 不通過傳遞參數 ByVal 獲得。MBV 由原始的組件作者執行。 怎么辦？如果讓我們建議一個兼顧性能與可靠性的合理配置，它們應是如下的配置：
這些是非常一般的原則，主機服務公司一般情況下以中或高隔離級運行 ASP，而單用途的 Web 服務器可以以低隔離級運行。衡量各種利弊，并自己決定哪個配置更能符合您的需要。 技巧 10：使用顯式選項在 .asp 文件中應使用 Option Explicit。此指令放在 .asp 文件的最上面，它強制開發人員聲明要使用到的所有變量。許多程序員認為這種方法對于調試應用程序很有幫助，因為這種方法避免了鍵錯變量名和誤建新變量的可能性（例如，將 MyXMLString=) 錯寫成 MyXLMString=...。 更重要的一點也許是，聲明的變量比未聲明的變量速度更快。由此，腳本在運行時每次用到未聲明的變量時，按名稱引用它。另一方面，聲明的變量是有順序的，要么以編譯時間，要么以運行時間。以后，聲明的變量都按此順序引用。因為 Option Explicit 強制變量聲明，它能確保聲明所有變量，因此訪問的速度也很快。 技巧 11：在子例程和函數中使用局部變量局部變量是那些在子例程和函數內聲明的變量。在函數或子例程內，局部變量訪問比全局變量訪問更快。局部變量的使用也會使代碼更清晰，因此應盡量使用局部變量。 技巧 12：將經常使用的數據復制到腳本變量中當訪問 ASP 中的 COM 對象時，應將經常使用的對象數據復制到腳本變量中。這樣做可減少 COM 方法調用，因為 COM 方法調用與訪問腳本變量相比，開銷相對較大。當訪問 Collection 和 Dictionary 對象時，這種技術也會減少開銷很大的查找。 一般來說，如果您打算不止一次訪問對象數據，那么就應將數據放到腳本變量中。這種優化的主要目標是 Request 變量（Form 和 QueryString 變量）。例如，您的站點可傳遞一個名為 UserID 的 QueryString 變量。假設此 UserID 在特定頁面上被引用 12 次。可以無須調用 Request(?UserID?) 12 次，而是在 ASP 頁面最上面將 UserID 指派到一個變量。然后在該頁面自始至終使用該變量。這樣就省去了 11 次 COM 方法調用。 實際上，訪問 COM 屬性或方法的開銷并沒有那么大。下面舉一個例子，說明某相當常見的代碼（從語法上講）： Foo.bar.blah.baz = Foo.bar.blah.qaz(1) If Foo.bar.blah.zaq = Foo.bar.blah.abc Then ' ... 當此代碼運行時，下面是發生的情況：
正如您可看到的，效率相當差（且慢）。以 VBScript 寫此代碼的快速方法是： Set myobj = Foo.bar.blah ' do the resolution of blah ONCE Myobj.baz = myobj.qaz(1) If Myobj.zaq = Myobj.abc Then '... 如果您使用 VBScript 5.0 或更高版本，您可以使用 With 語句寫此代碼： With Foo.bar.blah .baz = .qaz(1) If .zaq = .abc Then '... ... End With 注意此技巧也適用于 VB 程序設計。 技巧 13：避免重新確定數組的維數應盡量避免 Redim 數組。就性能而言，如果計算機的物理內存大小有限，最好將數組的初始維數設置為其最不利的情況 - 或將維數設置為其最佳的情況，然后再按需要重新確定維數。這并非意味著，如果知道您不需要內存時，就隨便分配幾兆字節的內存。 下面的代碼給您顯示使用 Dim 和 Redim 不當的情形。 <% Dim MyArray() Redim MyArray(2) MyArray(0) = ?hello? MyArray(1) = ?good-bye? MyArray(2) = ?farewell? ... ' some other code where you end up needing more space happens, then ... Redim Preserve MyArray(5) MyArray(3) = ?more stuff? MyArray(4) = ?even more stuff? MyArray(5) = ?yet more stuff? %> 最好一開始就將數組的初始大小 Dim 正確（在本例中，是 5）比 Redim 數組使其更大好得多。您可能浪費一些內存（如果您沒有使用所有的元素），但獲得的好處是速度變得更快。 技巧 14：使用響應緩沖您可以通過啟用“響應緩沖”，將要輸出的一整頁緩沖起來。這樣就將寫到瀏覽器的量減到最少，從而改善總體性能。每個寫操作都會產生很大的系統開銷（在 IIS 中以及在通過網絡發送的數據量方面），因此寫操作越少越好。由于其啟動慢且使用 Nagling 算法（用來減輕網絡塞車情況），TCP/IP 在發送一些大的數據塊時比必須發送許多小的數據塊時的效率高得多。 有兩個方法啟用響應緩沖。第一種，您可以使用 Internet Services Manager 為整個應用程序啟用響應緩沖。我們建議采用這種方法，在 IIS 4.0 和 IIS 5.0 中默認為新的 ASP 應用程序啟用響應緩沖。第二種，可以在每個 ASP 頁面的接近頂端的地方加入下面的代碼行，從而啟用響應緩沖： <% Response.Buffer = True %> 此代碼行必須在任何響應數據被寫到瀏覽器之前執行（即，在任何 HTML 出現在 ASP 腳本之前以及在使用 Response.Cookies 集合設置任何 Cookies 之前）。一般來說，最好為整個應用程序啟用響應緩沖。這樣，您就不必在每個頁面最上面寫入上述的代碼行。 Response.Flush關于響應緩沖有一個常見的抱怨，就是用戶感覺到 ASP 頁面的響應速度很慢（即使整個響應時間得到改進），因為他們必須等到整個頁面生成，然后他們才能看到東西。對于運行時間長的頁面，您可以設置 Response.Buffer = False，禁用響應緩沖。但是，一個更好的策略是利用 Response.Flush 方法。這種方法將 ASP 轉換的所有 HTML 送到瀏覽器。例如，在轉換 1,000 行的表的前 100 行之后，ASP 可以調用 Response.Flush，強制將轉換的結果送到瀏覽器，這樣可使用戶在其余的行準備好之前看到頭 100 行。這種技術可以將響應緩沖與瀏覽器逐漸顯示數據完美地結合在一起。 （注意在上面的 1,000 行表的舉例中，許多瀏覽器在它們看到關閉 標記之前不會開始顯示表。檢查您的目標瀏覽器是否支持。為避免這種情況，將表分成多個具有較少行的表，并在每個表之后調用 Response.Flush。較新版本的 Internet Explorer 在表完全下載之前就開始顯示表，如果您指定表列寬，顯示速度就會特別快，這樣做可避免強制 Internet Explorer 通過測量每個單元格的內容寬度來計算列寬。） 另一個關于響應緩沖的常見的抱怨是，當產生非常大的頁面時，將占用許多服務器內存。撇開產生大頁面的方法不談，這種問題也可通過巧妙使用 Response.Flush 來加以解決。 技巧 15：批處理內嵌腳本和 Response.Write 語句VBScript 語法 <% = expression %> 將“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 %> 下面的代碼更有效，每一行對響應流有一次寫操作。所有的代碼都包含在一個 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 %> 當禁用響應緩沖時，這一技巧的效果特別大。最好啟用響應緩沖，然后看批處理 Response.Write 是否有助于提高性能。 （在這一特定舉例中，建立表主體的嵌套循環 (While Not rs.EOF...) 可以用仔細構建的 GetString 調用來替代。） 技巧 16：如果頁面需要很長時間才能完成，那么執行前使用 Response.IsClientConnected如果用戶性急，他們可能會在您開始執行他們的請求之前，就會放棄 ASP 頁面。如果他們單擊刷新或移到服務器上的另一個頁面，在 ASP 請求隊列的末尾就有一個新的請求等候，在隊列的中間有一個斷開連接的請求。當服務器的負載很高時（因此請求隊列就會很長，響應時間也會相應地變長），就會經常發生這種情況，這樣只能使情況變得更糟。如果用戶不再連接，執行 ASP 頁面（特別是慢的、大的 ASP 頁面）已沒有任何意義。您可以使用 Response.IsClientConnected 屬性檢查這一情況。如果它返回 False，則應調用 Response.End 并放棄頁的其余部分。事實上，IIS 5.0 已將這一做法編為程序 - 每當 ASP 即將執行新請求時，它就會檢查請求在隊列中已等候了多長時間。如果已經在那里等候了多于 3 秒鐘，ASP 將檢查客戶機是否仍處于連接狀態，如果沒有連接，就立即終止請求。您可以在配置數據庫中使用 AspQueueConnectionTestTime 設置將超時時間由 3 秒調整為其它值。 如果頁面要花很長時間才能執行完，也可以不時地檢查 Response.IsClientConnected。當啟用了響應緩沖時，最好不時地執行 Response.Flush，以用戶知道，正在發生什么事。 注意 在 IIS 4.0 上，除非先執行了 Response.Write，否則 Response.IsClientConnected 就不能正常工作。如果啟用了緩沖，您也必須執行 Response.Flush。在 IIS 5.0 上，卻沒有必要這樣做，- Response.IsClientConnected 工作正常。在任何情況下，Response.IsClientConnected 都會有一些開銷，因此只有在一個操作至少要花（比方說） 500 毫秒（如果您想維持每秒鐘數十頁的吞吐量，這是一個很長的時間）才使用它。經驗表明，不要每次重復執行緊密循環時都調用它，如顯示表的許多行時 - 每隔二十或五十行調用一次可能比較合適。 技巧 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 頁面上。每個頁面不會產生編譯常量文件的開銷，且組件開發人員不必建立 VBScript#_include 文件以在 ASP 上使用。 要訪問 ADO TypeLib，將下面一條語句放在 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? --> |
溫馨提示：喜歡本站的話，請收藏一下本站！
本站發布的Win7純凈版系統、Win10純凈版和XP純凈版系統僅為個人學習測試使用，請在下載后24小時內刪除，不得用于任何商業用途，否則后果自負，請支持購買微軟正版軟件！
本站所有資源全部來自于網絡資源,如侵犯到您的權益,請及時通知我們(),我們會及時處理.
Copyright © 2018-2020 蘿卜系統下載站 手機站 關于本站
