通過(guò)腳本程序啟動(dòng)緩沖器
　　在ASP腳本的頂部包含Response.Buffer=True ，IIS就會(huì)將頁(yè)面的內(nèi)容緩存。

　　< % OPTION EXPLICIT
　　Response.Buffer = true
　　Dim FirstName
　　…

　　/app1/buffer__1.asp的片段

　　以前的最佳（反應(yīng)時(shí)間）= 7.05 msec/page
　　反應(yīng)時(shí)間 = 6.08 msec/page
　　差= -0.97 msec (降低13.7%)

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

　　通過(guò)服務(wù)器配置啟動(dòng)緩沖器

　　雖然在IIS 5.0中緩沖器是被默認(rèn)啟動(dòng)的，但是在IIS 4.0中還必須手動(dòng)來(lái)啟動(dòng)它。這時(shí)要找到站點(diǎn)的Properties 對(duì)話(huà)框，在那里，從Home Directory 標(biāo)簽中選擇配置按鈕。然后在"App options"下選擇"enable buffering" 。對(duì)于這個(gè)測(cè)試，Response.Buffer 語(yǔ)句從腳本中被移走了。

　　以前的最佳= 7.05 msec/page
　　反應(yīng)時(shí)間 = 5.57 msec/page
　　差= -1.48 msec (降低 21.0%)

　　目前，這是我們所得到的最快反應(yīng)了，比我們以前最好情況下的反應(yīng)時(shí)間還要降低21%。從現(xiàn)在開(kāi)始，我們以后的測(cè)試都要把這個(gè)反應(yīng)時(shí)間作為基準(zhǔn)值。

　　回顧及觀測(cè)

　　緩沖器是提高性能的好方法，所以把緩沖器設(shè)置成服務(wù)器的默認(rèn)值很有必要。如果因?yàn)槟承┰?，?yè)面不能正確地使緩沖器運(yùn)行，只需要Response.Buffer=False 命令即可。緩沖器的一個(gè)缺點(diǎn)是在整個(gè)頁(yè)面處理完之前，用戶(hù)從服務(wù)器看不到任何東西。因此，在復(fù)雜頁(yè)面的處理期間，偶而調(diào)用一次Response.Flush 來(lái)更新用戶(hù)是個(gè)好主意。

　　現(xiàn)在在我們的規(guī)則中又增加了一條：總是通過(guò)服務(wù)器設(shè)置開(kāi)啟緩沖器。

是否應(yīng)該考慮向ASP代碼中增加注釋?zhuān)?

　　大部分HTML開(kāi)發(fā)人員都知道包含HTML注釋不是個(gè)好主意，首先會(huì)增加傳輸數(shù)據(jù)的規(guī)模，其次它們只是向別的開(kāi)發(fā)人員提供有關(guān)你頁(yè)面組織的信息。但是ASP頁(yè)面上的注釋又如何呢？它們從來(lái)不離開(kāi)服務(wù)器，但也確實(shí)要增加頁(yè)面的規(guī)模，因此必須用ASP進(jìn)行分解。

　　在這次的測(cè)試中，我們?cè)黾?0條注釋?zhuān)織l有80個(gè)字符，總共有1600個(gè)字符。

　　< % OPTION EXPLICIT
　　'-------------------------------------------------------------------------------
　　… 20 lines …
　　'-------------------------------------------------------------------------------
　 　Dim FirstName
　　 …

　　/app2/comment_1.asp片段

　　基準(zhǔn)= 5.57 msec/page
　　反應(yīng)時(shí)間= 5.58 msec/page
　　差 = +0.01 msec (增加 0.1%)

　　測(cè)試的結(jié)果是驚人的。雖然注釋幾乎相當(dāng)于文件本身的兩倍，但是它們的存在并沒(méi)有給反應(yīng)時(shí)間帶來(lái)很大的影響。所以說(shuō)我們可以遵循以下規(guī)則：

　　只要使用適度，ASP注釋對(duì)性能的影響很小或根本沒(méi)有影響。

是否應(yīng)該為頁(yè)面明確地設(shè)置默認(rèn)語(yǔ)言？

　　IIS處理VBScript是默認(rèn)的設(shè)置，但是我看到，在大多數(shù)例子中還是用< %@LANGUAGE=VBSCRIPT% >聲明將語(yǔ)言明確地設(shè)置為VBScript 。我們的下一個(gè)測(cè)試將檢驗(yàn)這個(gè)聲明的存在對(duì)性能有什么影響。

　　< %@ LANGUAGE=VBSCRIPT % >
　　< % OPTION EXPLICIT
　　Dim FirstName
　　…

　　/app2/language1.asp片段。

　　基準(zhǔn)值= 5.57 msec/page
　　反應(yīng)時(shí)間= 5.64 msec/page
　　差= +0.07 msec (增加1.2%)

　　可以看到，包含了語(yǔ)言的聲明對(duì)性能有一個(gè)輕微的影響。因此：

　　* 設(shè)置服務(wù)器的默認(rèn)語(yǔ)言配置以與站點(diǎn)上使用的語(yǔ)言相匹配。
　　* 除非你使用非默認(rèn)語(yǔ)言，不要設(shè)置語(yǔ)言聲明。

如果不需要，是否應(yīng)該關(guān)閉Session 狀態(tài)？

　　避免使用IIS的Session上下文有許多理由，那些已經(jīng)可以獨(dú)立成為一篇文章。我們現(xiàn)在試圖回答的問(wèn)題是當(dāng)頁(yè)面不需要時(shí)，關(guān)閉Session上下文是否對(duì)性能提高有所幫助。從理論上講應(yīng)該是肯定的，因?yàn)檫@樣一來(lái)就不需要用頁(yè)面例示Session上下文了。

　　同緩沖器一樣，Session狀態(tài)也有兩種配置方法：通過(guò)腳本和通過(guò)服務(wù)器設(shè)置。

　　通過(guò)腳本關(guān)閉Session上下文

　　對(duì)于這個(gè)測(cè)試，要關(guān)閉頁(yè)面中的Session上下文，我增加一個(gè)Session狀態(tài)聲明。

　　< %@ ENABLESESSIONSTATE = FALSE % >
　　< % OPTION EXPLICIT
　Dim FirstName
　 …

　　/app2/session_1.asp片段。

　　基準(zhǔn)值= 5.57 msec/page
　　反應(yīng)時(shí)間= 5.46 msec/page
　　差= -0.11 msec (降低2.0%)

　　只通過(guò)這樣一個(gè)小小的努力就得到了不錯(cuò)的進(jìn)步?，F(xiàn)在看看第二部分。

　　通過(guò)服務(wù)器配置關(guān)閉Session 上下文

　　要在服務(wù)器上關(guān)閉Session 上下文，請(qǐng)到站點(diǎn)的Properties 對(duì)話(huà)框。在Home Directory 標(biāo)簽上選擇Configuration 按鈕。然后在"App options"下取消"enable session state" 的選擇。我們?cè)跊](méi)有ENABLESESSIONSTATE 聲明的情況下運(yùn)行測(cè)試。

　　基準(zhǔn)值 = 5.57 msec/page
　　反應(yīng)時(shí)間= 5.14 msec/page
　　差= -0.43 msec (降低7.7%)

　　這是性能的又一個(gè)顯著提高。所以，我們的規(guī)則應(yīng)是：在不需要的情況下，總是在頁(yè)面或應(yīng)用程序的水平上關(guān)閉Session狀態(tài)。

使用Option Explicit 會(huì)使性能有實(shí)質(zhì)改變嗎？

　　在一個(gè)ASP頁(yè)面的頂部設(shè)置Option Explicit 以要求所有的變量在使用之前都要在頁(yè)面上進(jìn)行聲明。這有兩個(gè)原因。首先應(yīng)用程序可以更快地處理變量的存取。其次，這樣可以防止我們無(wú)意中錯(cuò)用變量的名字。在這個(gè)測(cè)試中我們移走Option Explicit 引用和變量的Dim 聲明。

　　基準(zhǔn)值 = 5.57 msec/page
　　反應(yīng)時(shí)間= 6.12 msec/page
　　差 = +0.55 msec (9.8% 增加)、

　　盡管有一些代碼行從頁(yè)面中去掉了，反應(yīng)時(shí)間卻依然增加了。所以盡管使用Option explicit 有時(shí)候費(fèi)時(shí)間，但是在性能上卻有很顯著的效果。因此我們又可以增加一條規(guī)則：在VBScript中總是使用Option explicit。

是否應(yīng)該把腳本邏輯放在子程序和函數(shù)區(qū)？

　　用函數(shù)和子程序來(lái)組織和管理代碼是一個(gè)很好的方法，特別是當(dāng)一個(gè)代碼區(qū)在頁(yè)面中多次使用的情況。缺點(diǎn)是要在系統(tǒng)上增加一個(gè)做相同工作的額外函數(shù)調(diào)用。子程序和函數(shù)的另一個(gè)問(wèn)題是變量的范圍。從理論上說(shuō)，在一個(gè)函數(shù)區(qū)內(nèi)指定變量更有效?，F(xiàn)在我們看看這兩個(gè)方面如何發(fā)生作用。

　　將Response.Write 語(yǔ)句移入子程序

　　這個(gè)測(cè)試只是將Response.Write 語(yǔ)句移入一個(gè)子程序區(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片段

　　基準(zhǔn)值= 5.57 msec/page
　　反應(yīng)時(shí)間= 6.02 msec/page
　　差 = +0.45 msec (8.1% 增加)

　　同預(yù)料中一樣，子程序調(diào)用給頁(yè)面帶來(lái)了額外的負(fù)擔(dān)。

　　將所有腳本移入子程序中

　　在這個(gè)測(cè)試中，Response.write 語(yǔ)句與變量聲明都移入一個(gè)子程序區(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片段

　　基準(zhǔn)值= 5.57 msec/page
　　反應(yīng)時(shí)間= 5.22 msec/page
　　差 = -0.35 msec (6.3% 降低)

　　非常有趣！盡管將變量移到函數(shù)范圍內(nèi)增加了額外的函數(shù)調(diào)用，但實(shí)際上卻提高了性能。我們又可以增加以下規(guī)則：

　　* 在一個(gè)頁(yè)面上，如果代碼要使用一次以上，就將代碼封入函數(shù)區(qū)。
　　* 適當(dāng)時(shí)候，將變量聲明移到函數(shù)范圍內(nèi)。

使用包含文件有什么影響？

　　ASP編程的一個(gè)重要功能就是包含來(lái)自其它頁(yè)面的代碼。通過(guò)這項(xiàng)功能，程序員可以在多個(gè)頁(yè)面上共享函數(shù)，使代碼更易于維護(hù)。缺點(diǎn)在于服務(wù)器必須從多個(gè)來(lái)源組裝頁(yè)面。以下是使用Include文件的兩個(gè)測(cè)試。

　　使用內(nèi)聯(lián)代碼的Include 文件

　　在這個(gè)測(cè)試中，有一小段代碼被移到一個(gè)Include 文件中：

　　< % OPTION EXPLICIT
　　Dim FirstName
　 　…
　　 Dim BirthDate
　　FirstName = "John"
　　…
　　BirthDate = "1/1/1950"
　　% >

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

　　/app2/include_1.asp片段

　　基準(zhǔn)值 = 5.57 msec/page
　　反應(yīng)時(shí)間= 5.93 msec/page
　　差 = +0.36 msec (6.5% 增加)

　　這不奇怪。使用Include 文件形成了負(fù)載。

　　在函數(shù)區(qū)使用Include 文件

　　在這里，代碼都包裝在一個(gè)Include 文件中的子程序里。Include 引用是在頁(yè)面頂部進(jìn)行的，在ASP腳本的適當(dāng)位置調(diào)用子程序。

　　< % OPTION EXPLICIT
　　Dim FirstName
　　…
　　Dim BirthDate
　　FirstName = "John"
　　…
　　BirthDate = "1/1/1950"
　　CALL writeTable()
　　% >

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

　　/app2/include_2.asp片段

　　基準(zhǔn)值 = 5.57 msec/page
　　反應(yīng)時(shí)間= 6.08 msec/page
　差 =+0.51 msec (9.2% 增加)

　　這對(duì)性能造成的影響比f(wàn)unctions調(diào)用還大。因此：只有當(dāng)代碼在頁(yè)面之間共享時(shí)才使用Include 文件。

執(zhí)行錯(cuò)誤處理時(shí)會(huì)形成多大的負(fù)載？

　　對(duì)于所有真正的應(yīng)用程序來(lái)說(shuō)，錯(cuò)誤處理都是必要的。這個(gè)測(cè)試中，通過(guò)調(diào)用On Error Resume Next函數(shù)來(lái)調(diào)用錯(cuò)誤句柄。

　　< % OPTION EXPLICIT
　　On Error Resume Next
　　Dim FirstName
　　…

　　/app2/error_1.asp片段

　　基準(zhǔn)值 = 5.57 msec/page
　　反應(yīng)時(shí)間= 5.67 msec/page
　　差= 0.10 msec (1.8% 增加)

　　你可以看到，錯(cuò)誤句柄帶來(lái)了代價(jià)。我們可以提出以下建議：只有在會(huì)發(fā)生超出測(cè)試或控制能力之外的情況時(shí)才使用錯(cuò)誤句柄。一個(gè)最基本的例子就是使用存取其它資源，如ADO或FileSystem 對(duì)象的COM對(duì)象。

設(shè)置一個(gè)上下文處理是否對(duì)性能有影響？

　　當(dāng)錯(cuò)誤發(fā)生時(shí)，在頁(yè)面上設(shè)置一個(gè)上下文處理允許腳本進(jìn)行反轉(zhuǎn)操作。這是通過(guò)在頁(yè)面上使用處理聲明來(lái)設(shè)置的。

　　< %@ TRANSACTION = REQUIRED % >
　　< % OPTION EXPLICIT
　　Dim FirstName
　　…

　　/app2/transact1.asp片段

　　基準(zhǔn)值 = 5.57 msec/page
　　反應(yīng)時(shí)間= 13.39 msec/page
　　差 = +7.82 msec (140.4% 增加)

　　??！這真實(shí)最具有戲劇性的結(jié)果。所以請(qǐng)留意以下規(guī)則：只有當(dāng)兩個(gè)或更多操作被作為一個(gè)單元執(zhí)行時(shí)，才使用處理上下文。