提高ASP效能的最佳選擇2

效能

　　是否應該開啟緩衝器？

　　通過指令碼程式啟動緩衝器

　　在ASP指令碼的頂部包含Response.Buffer=True ，IIS就會將頁面的內容緩衝。

　　< % OPTION EXPLICIT

　　Response.Buffer = true

　　Dim FirstName

　　…

　　/app1/buffer__1.asp的片段

　　以前的最佳（反應時間）= 7.05 msec/page

　　反應時間 = 6.08 msec/page

　　差= -0.97 msec (降低13.7%)

　　效能得到了極大提高。但是等等，還能有更好的。

　　通過伺服器配置啟動緩衝器

　　雖然在IIS 5.0中緩衝器是被預設啟動的，但是在IIS 4.0中還必須手動來啟動它。這時要找到網站的Properties 對話方塊，在那裡，從Home Directory 標籤中選擇配置按鈕。然後在"App options"下選擇"enable buffering" 。對於這個測試，Response.Buffer 語句從指令碼中被移走了。

　　以前的最佳= 7.05 msec/page

　　反應時間 = 5.57 msec/page

　　差= -1.48 msec (降低 21.0%)

　　目前，這是我們所得到的最快反應了，比我們以前最好情況下的反應時間還要降低21%。從現在開始，我們以後的測試都要把這個反應時間作為基準值。

　　回顧及觀測

　　緩衝器是提高效能的好方法，所以把緩衝器設定成伺服器的預設值很有必要。如果因為某些原因，頁面不能正確地使緩衝器運行，只需要Response.Buffer=False 命令即可。緩衝器的一個缺點是在整個頁面處理完之前，使用者從伺服器看不到任何東西。因此，在複雜頁面的處理期間，偶而調用一次Response.Flush 來更新使用者是個好主意。

　　現在在我們的規則中又增加了一條：總是通過伺服器設定開啟緩衝器。

　　是否應該考慮向ASP代碼中增加註釋？

　　大部分HTML開發人員都知道包含HTML注釋不是個好主意，首先會增加傳輸資料的規模，其次它們只是向別的開發人員提供有關你頁面組織的資訊。但是ASP頁面上的注釋又如何呢？它們從來不離開伺服器，但也確實要增加頁面的規模，因此必須用ASP進行分解。

　　在這次的測試中，我們增加20條注釋，每條有80個字元，總共有1600個字元。

　　< % OPTION EXPLICIT

　　'-------------------------------------------------------------------------------

　　… 20 lines …

　　'-------------------------------------------------------------------------------

　　Dim FirstName

　　…

　　/app2/comment_1.asp片段

　　基準= 5.57 msec/page

　　反應時間= 5.58 msec/page

　　差 = +0.01 msec (增加 0.1%)

　　測試的結果是驚人的。雖然注釋幾乎相當於檔案本身的兩倍，但是它們的存在並沒有給反應時間帶來很大的影響。所以說我們可以遵循以下規則：

　　只要使用適度，ASP注釋對效能的影響很小或根本沒有影響。

　　是否應該為頁面明確地設定預設語言？

　　IIS處理VBScript是預設的設定，但是我看到，在大多數例子中還是用< %@LANGUAGE=VBSCRIPT% >聲明將語言明確地設定為VBScript 。我們的下一個測試將檢驗這個聲明的存在對效能有什麼影響。

　　< %@ LANGUAGE=VBSCRIPT % >

　　< % OPTION EXPLICIT

　　Dim FirstName

　　…

　　/app2/language1.asp片段。

　　基準值= 5.57 msec/page

　　反應時間= 5.64 msec/page

　　差= +0.07 msec (增加1.2%)

　　可以看到，包含了語言的聲明對效能有一個輕微的影響。因此：

　　* 設定伺服器的預設語言配置以與網站上使用的語言相匹配。

　　* 除非你使用非預設語言，不要設定語言聲明。

　　如果不需要，是否應該關閉Session 狀態？

　　避免使用IIS的Session上下文有許多理由，那些已經可以獨立成為一篇文章。我們現在試圖回答的問題是當頁面不需要時，關閉Session上下文是否對效能提高有所協助。從理論上講應該是肯定的，因為這樣一來就不需要用頁面例示Session上下文了。

　　同緩衝器一樣，Session狀態也有兩種配置方法：通過指令碼和通過伺服器設定。

　　通過指令碼關閉Session上下文

　　對於這個測試，要關閉頁面中的Session上下文，我增加一個Session狀態聲明。

　　< %@ ENABLESESSIONSTATE = FALSE % >

　　< % OPTION EXPLICIT

　　Dim FirstName

　　…

　　/app2/session_1.asp片段。

　　基準值= 5.57 msec/page

　　反應時間= 5.46 msec/page

　　差= -0.11 msec (降低2.0%)

　　只通過這樣一個小小的努力就得到了不錯的進步。現在看看第二部分。

　　通過伺服器配置關閉Session 上下文

　　要在伺服器上關閉Session 上下文，請到網站的Properties 對話方塊。在Home Directory 標籤上選擇Configuration 按鈕。然後在"App options"下取消"enable session state" 的選擇。我們在沒有ENABLESESSIONSTATE 聲明的情況下運行測試。

　　基準值 = 5.57 msec/page

　　反應時間= 5.14 msec/page

　　差= -0.43 msec (降低7.7%)

　　這是效能的又一個顯著提高。所以，我們的規則應是：在不需要的情況下，總是在頁面或應用程式的水平上關閉Session狀態。

　　使用Option Explicit 會使效能有實質改變嗎？

　　在一個ASP頁面的頂部設定Option Explicit 以要求所有的變數在使用之前都要在頁面上進行聲明。這有兩個原因。首先應用程式可以更快地處理變數的存取。其次，這樣可以防止我們無意中錯用變數的名字。在這個測試中我們移走Option Explicit 引用和變數的Dim 聲明。

　　基準值 = 5.57 msec/page

　　反應時間= 6.12 msec/page

　　差 = +0.55 msec (9.8% 增加)、

　　儘管有一些程式碼從頁面中去掉了，反應時間卻依然增加了。所以儘管使用Option explicit 有時候費時間，但是在效能上卻有很顯著的效果。因此我們又可以增加一條規則：在VBScript中總是使用Option explicit。

　　是否應該把指令碼邏輯放在子程式和函數區？

　　用函數和子程式來組織和管理代碼是一個很好的方法，特別是當一個代碼區在頁面中多次使用的情況。缺點是要在系統上增加一個做相同工作的額外函數調用。子程式和函數的另一個問題是變數的範圍。從理論上說，在一個函數區內指定變數更有效。現在我們看看這兩個方面如何發生作用。

　　將Response.Write 語句移入子程式

　　這個測試只是將Response.Write 語句移入一個子程式區內。

　　…

　　CALL writeTable()

　　SUB writeTable()

　　Response.Write("< html >" & _

　　"< head >" & _

　　…

　　"< tr >< td >< b >EMail:< /b >< /td >< td >" & EMail & "< /td >< /tr >" & _

　　"< tr >< td >< b >Birth Date:< /b >< /td >< td >" & BirthDate & "< /td >< /tr >" & _

　　"< /table >" & _

　　"< /body >" & _

　　"< /html >")

　　END SUB

　　/app2/function1.asp片段

　　基準值= 5.57 msec/page

　　反應時間= 6.02 msec/page

　　差 = +0.45 msec (8.1% 增加)

　　同預料中一樣，子程式調用給頁面帶來了額外的負擔。

　　將所有指令碼移入子程式中

　　在這個測試中，Response.write 語句與變數聲明都移入一個子程式區中。

　　< % OPTION EXPLICIT

　　CALL writeTable()

　　SUB writeTable()

　　Dim FirstName

　　…

　　Dim BirthDate

　　FirstName = "John"

　　…

　　BirthDate = "1/1/1950"

　　Response.Write("< html >" & _

　　"< head >" & _

　　" < title >Response Test< /title >" & _

　　"< /head >" & _

　　"< body >" & _

　　"< h1 >Response Test< /h1 >" & _

　　"< table >" & _

　　"< tr >< td >< b >First Name:< /b >< /td >< td >" & FirstName & "< /td >< /tr >" & _

　　…

　　"< tr >< td >< b >Birth Date:< /b >< /td >< td >" & BirthDate & "< /td >< /tr >" & _

　　"< /table >" & _

　　"< /body >" & _

　　"< /html >")

　　END SUB

　　/app2/function2.asp片段

　　基準值= 5.57 msec/page

　　反應時間= 5.22 msec/page

　　差 = -0.35 msec (6.3% 降低)

　　非常有趣！儘管將變數移到函數範圍內增加了額外的函數調用，但實際上卻提高了效能。我們又可以增加以下規則：

　　* 在一個頁面上，如果代碼要使用一次以上，就將代碼封入函數區。

　　* 適當時候，將變數聲明移到函數範圍內。

　　使用包含檔案有什麼影響？

　　ASP編程的一個重要功能就是包含來自其它頁面的代碼。通過這項功能，程式員可以在多個頁面上共用函數，使代碼更易於維護。缺點在於伺服器必須從多個來源組裝頁面。以下是使用Include檔案的兩個測試。

　　使用內聯代碼的Include 檔案

　　在這個測試中，有一小段代碼被移到一個Include 檔案中：

　　< % OPTION EXPLICIT

　　Dim FirstName

　　…

　　Dim BirthDate

　　FirstName = "John"

　　…

　　BirthDate = "1/1/1950"

　　% >

　　< !-- #include file="inc1.asp" -- >

　　/app2/include_1.asp片段

　　基準值 = 5.57 msec/page

　　反應時間= 5.93 msec/page

　　差 = +0.36 msec (6.5% 增加)

　　這不奇怪。使用Include 檔案形成了負載。

　　在函數區使用Include 檔案

　　在這裡，代碼都封裝在一個Include 檔案中的子程式裡。Include 引用是在頁面頂部進行的，在ASP指令碼的適當位置調用子程式。

　　< % OPTION EXPLICIT

　　Dim FirstName

　　…

　　Dim BirthDate

　　FirstName = "John"

　　…

　　BirthDate = "1/1/1950"

　　CALL writeTable()

　　% >

　　< !-- #include file="inc2.asp" -- >

　　/app2/include_2.asp片段

　　基準值 = 5.57 msec/page

　　反應時間= 6.08 msec/page

　　差 =+0.51 msec (9.2% 增加)

　　這對效能造成的影響比functions調用還大。因此：只有當代碼在頁面之間共用時才使用Include 檔案。

　　執行錯誤處理時會形成多大的負載？

　　對於所有真正的應用程式來說，錯誤處理都是必要的。這個測試中，通過調用On Error Resume Next函數來調用錯誤控制代碼。

　　< % OPTION EXPLICIT

　　On Error Resume Next

　　Dim FirstName

　　…

　　/app2/error_1.asp片段

　　基準值 = 5.57 msec/page

　　反應時間= 5.67 msec/page

　　差= 0.10 msec (1.8% 增加)

　　你可以看到，錯誤控制代碼帶來了代價。我們可以提出以下建議：只有在會發生超出測試或控制能力之外的情況時才使用錯誤控制代碼。一個最基本的例子就是使用存取其它資源，如ADO或FileSystem 對象的COM對象。

　　設定一個上下文處理是否對效能有影響？

　　當錯誤發生時，在頁面上設定一個上下文處理允許指令碼進行反轉操作。這是通過在頁面上使用處理聲明來設定的。

　　< %@ TRANSACTION = REQUIRED % >

　　< % OPTION EXPLICIT

　　Dim FirstName

　　…

　　/app2/transact1.asp片段

　　基準值 = 5.57 msec/page

　　反應時間= 13.39 msec/page

　　差 = +7.82 msec (140.4% 增加)

　　啊！這真實最具有戲劇性的結果。所以請留意以下規則：只有當兩個或更多操作被作為一個單元執行時，才使用處理上下文。