|
是否應(yīng)該開啟緩沖器？
通過腳本程序啟動緩沖器
在ASP腳本的頂部包含Response.Buffer=True ，IIS就會將頁面的內(nèi)容緩存。
< % OPTION EXPLICIT
Response.Buffer = true
Dim FirstName
…
/app1/buffer__1.asp的片段
以前的最佳（反應(yīng)時間）= 7.05 msec/page
反應(yīng)時間 = 6.08 msec/page
差= -0.97 msec (降低13.7%)
性能得到了極大提高。但是等等，還能有更好的。
通過服務(wù)器配置啟動緩沖器
雖然在IIS 5.0中緩沖器是被默認啟動的，但是在IIS 4.0中還必須手動來啟動它。這時要找到站點的Properties 對話框，在那里，從Home Directory 標簽中選擇配置按鈕。然后在"App options"下選擇"enable buffering" 。對于這個測試，Response.Buffer 語句從腳本中被移走了。
以前的最佳= 7.05 msec/page
反應(yīng)時間 = 5.57 msec/page
差= -1.48 msec (降低 21.0%)
目前，這是我們所得到的最快反應(yīng)了，比我們以前最好情況下的反應(yīng)時間還要降低21%。從現(xiàn)在開始，我們以后的測試都要把這個反應(yīng)時間作為基準值。
回顧及觀測
緩沖器是提高性能的好方法，所以把緩沖器設(shè)置成服務(wù)器的默認值很有必要。如果因為某些原因，頁面不能正確地使緩沖器運行，只需要Response.Buffer=False 命令即可。緩沖器的一個缺點是在整個頁面處理完之前，用戶從服務(wù)器看不到任何東西。因此，在復(fù)雜頁面的處理期間，偶而調(diào)用一次Response.Flush 來更新用戶是個好主意。
現(xiàn)在在我們的規(guī)則中又增加了一條：總是通過服務(wù)器設(shè)置開啟緩沖器。
是否應(yīng)該考慮向ASP代碼中增加注釋？
大部分HTML開發(fā)人員都知道包含HTML注釋不是個好主意，首先會增加傳輸數(shù)據(jù)的規(guī)模，其次它們只是向別的開發(fā)人員提供有關(guān)你頁面組織的信息。但是ASP頁面上的注釋又如何呢？它們從來不離開服務(wù)器，但也確實要增加頁面的規(guī)模，因此必須用ASP進行分解。
在這次的測試中，我們增加20條注釋，每條有80個字符，總共有1600個字符。
< % OPTION EXPLICIT
'-------------------------------------------------------------------------------
… 20 lines …
'-------------------------------------------------------------------------------
Dim FirstName
…
/app2/comment_1.asp片段
基準= 5.57 msec/page
反應(yīng)時間= 5.58 msec/page
差 = +0.01 msec (增加 0.1%)
測試的結(jié)果是驚人的。雖然注釋幾乎相當于文件本身的兩倍，但是它們的存在并沒有給反應(yīng)時間帶來很大的影響。所以說我們可以遵循以下規(guī)則：
只要使用適度，ASP注釋對性能的影響很小或根本沒有影響。
是否應(yīng)該為頁面明確地設(shè)置默認語言？
IIS處理VBScript是默認的設(shè)置，但是我看到，在大多數(shù)例子中還是用< %@LANGUAGE=VBSCRIPT% >聲明將語言明確地設(shè)置為VBScript 。我們的下一個測試將檢驗這個聲明的存在對性能有什么影響。
< %@ LANGUAGE=VBSCRIPT % >
< % OPTION EXPLICIT
Dim FirstName
…
/app2/language1.asp片段。
基準值= 5.57 msec/page
反應(yīng)時間= 5.64 msec/page
差= +0.07 msec (增加1.2%)
可以看到，包含了語言的聲明對性能有一個輕微的影響。因此：
* 設(shè)置服務(wù)器的默認語言配置以與站點上使用的語言相匹配。
* 除非你使用非默認語言，不要設(shè)置語言聲明。
如果不需要，是否應(yīng)該關(guān)閉Session 狀態(tài)？
避免使用IIS的Session上下文有許多理由，那些已經(jīng)可以獨立成為一篇文章。我們現(xiàn)在試圖回答的問題是當頁面不需要時，關(guān)閉Session上下文是否對性能提高有所幫助。從理論上講應(yīng)該是肯定的，因為這樣一來就不需要用頁面例示Session上下文了。
同緩沖器一樣，Session狀態(tài)也有兩種配置方法：通過腳本和通過服務(wù)器設(shè)置。
通過腳本關(guān)閉Session上下文
對于這個測試，要關(guān)閉頁面中的Session上下文，我增加一個Session狀態(tài)聲明。
< %@ ENABLESESSIONSTATE = FALSE % >
< % OPTION EXPLICIT
Dim FirstName
…
/app2/session_1.asp片段。
基準值= 5.57 msec/page
反應(yīng)時間= 5.46 msec/page
差= -0.11 msec (降低2.0%)
只通過這樣一個小小的努力就得到了不錯的進步。現(xiàn)在看看第二部分。
通過服務(wù)器配置關(guān)閉Session 上下文
要在服務(wù)器上關(guān)閉Session 上下文，請到站點的Properties 對話框。在Home Directory 標簽上選擇Configuration 按鈕。然后在"App options"下取消"enable session state" 的選擇。我們在沒有ENABLESESSIONSTATE 聲明的情況下運行測試。
基準值 = 5.57 msec/page
反應(yīng)時間= 5.14 msec/page
差= -0.43 msec (降低7.7%)
這是性能的又一個顯著提高。所以，我們的規(guī)則應(yīng)是：在不需要的情況下，總是在頁面或應(yīng)用程序的水平上關(guān)閉Session狀態(tài)。
使用Option Explicit 會使性能有實質(zhì)改變嗎？
在一個ASP頁面的頂部設(shè)置Option Explicit 以要求所有的變量在使用之前都要在頁面上進行聲明。這有兩個原因。首先應(yīng)用程序可以更快地處理變量的存取。其次，這樣可以防止我們無意中錯用變量的名字。在這個測試中我們移走Option Explicit 引用和變量的Dim 聲明。
基準值 = 5.57 msec/page
反應(yīng)時間= 6.12 msec/page
差 = +0.55 msec (9.8% 增加)、
盡管有一些代碼行從頁面中去掉了，反應(yīng)時間卻依然增加了。所以盡管使用Option explicit 有時候費時間，但是在性能上卻有很顯著的效果。因此我們又可以增加一條規(guī)則：在VBScript中總是使用Option explicit。
是否應(yīng)該把腳本邏輯放在子程序和函數(shù)區(qū)？
用函數(shù)和子程序來組織和管理代碼是一個很好的方法，特別是當一個代碼區(qū)在頁面中多次使用的情況。缺點是要在系統(tǒng)上增加一個做相同工作的額外函數(shù)調(diào)用。子程序和函數(shù)的另一個問題是變量的范圍。從理論上說，在一個函數(shù)區(qū)內(nèi)指定變量更有效。現(xiàn)在我們看看這兩個方面如何發(fā)生作用。
將Response.Write 語句移入子程序
這個測試只是將Response.Write 語句移入一個子程序區(qū)內(nèi)。
…
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
反應(yīng)時間= 6.02 msec/page
差 = +0.45 msec (8.1% 增加)
同預(yù)料中一樣，子程序調(diào)用給頁面帶來了額外的負擔(dān)。
將所有腳本移入子程序中
在這個測試中，Response.write 語句與變量聲明都移入一個子程序區(qū)中。
< % 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
反應(yīng)時間= 5.22 msec/page
差 = -0.35 msec (6.3% 降低)
非常有趣！盡管將變量移到函數(shù)范圍內(nèi)增加了額外的函數(shù)調(diào)用，但實際上卻提高了性能。我們又可以增加以下規(guī)則：
* 在一個頁面上，如果代碼要使用一次以上，就將代碼封入函數(shù)區(qū)。
* 適當時候，將變量聲明移到函數(shù)范圍內(nèi)。
使用包含文件有什么影響？
ASP編程的一個重要功能就是包含來自其它頁面的代碼。通過這項功能，程序員可以在多個頁面上共享函數(shù)，使代碼更易于維護。缺點在于服務(wù)器必須從多個來源組裝頁面。以下是使用Include文件的兩個測試。
使用內(nèi)聯(lián)代碼的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
反應(yīng)時間= 5.93 msec/page
差 = +0.36 msec (6.5% 增加)
這不奇怪。使用Include 文件形成了負載。
在函數(shù)區(qū)使用Include 文件
在這里，代碼都包裝在一個Include 文件中的子程序里。Include 引用是在頁面頂部進行的，在ASP腳本的適當位置調(diào)用子程序。
< % 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
反應(yīng)時間= 6.08 msec/page
差 =+0.51 msec (9.2% 增加)
這對性能造成的影響比functions調(diào)用還大。因此：只有當代碼在頁面之間共享時才使用Include 文件。
執(zhí)行錯誤處理時會形成多大的負載？
對于所有真正的應(yīng)用程序來說，錯誤處理都是必要的。這個測試中，通過調(diào)用On Error Resume Next函數(shù)來調(diào)用錯誤句柄。
< % OPTION EXPLICIT
On Error Resume Next
Dim FirstName
…
/app2/error_1.asp片段
基準值 = 5.57 msec/page
反應(yīng)時間= 5.67 msec/page
差= 0.10 msec (1.8% 增加)
你可以看到，錯誤句柄帶來了代價。我們可以提出以下建議：只有在會發(fā)生超出測試或控制能力之外的情況時才使用錯誤句柄。一個最基本的例子就是使用存取其它資源，如ADO或FileSystem 對象的COM對象。
設(shè)置一個上下文處理是否對性能有影響？
當錯誤發(fā)生時，在頁面上設(shè)置一個上下文處理允許腳本進行反轉(zhuǎn)操作。這是通過在頁面上使用處理聲明來設(shè)置的。
< %@ TRANSACTION = REQUIRED % >
< % OPTION EXPLICIT
Dim FirstName
…
/app2/transact1.asp片段
基準值 = 5.57 msec/page
反應(yīng)時間= 13.39 msec/page
差 = +7.82 msec (140.4% 增加)
啊！這真實最具有戲劇性的結(jié)果。所以請留意以下規(guī)則：只有當兩個或更多操作被作為一個單元執(zhí)行時，才使用處理上下文。
| 
