ASP性能如何提高

ASP開發(fā)人員為了在他們的設(shè)計(jì)項(xiàng)目中獲得更好的性能和可擴(kuò)展性而不斷努力。幸運(yùn)地是，有許多書籍和站點(diǎn)在這方面提供了很好的建議。但是這些建議的基礎(chǔ)都是從ASP平臺工作的結(jié)構(gòu)上所得出的結(jié)論，對實(shí)際獲得的性能的提高沒有量的測量。由于這些建議需要更加復(fù)雜的編碼過程并降低了編碼的可讀性，開發(fā)人員就只能在看不到實(shí)際運(yùn)行效果的情況下，獨(dú)自衡量為了提高他們ASP應(yīng)用程序的性能是否值得付出這些代價(jià)。
　　本文分為兩大部分，我將介紹一些性能測試結(jié)果，幫助開發(fā)人員來確定某一特定舉措是否不僅對將來的項(xiàng)目來說是值得的，并且能夠?qū)υ瓉淼捻?xiàng)目進(jìn)行更新。在第一部分我將回顧一些ASP開發(fā)的基礎(chǔ)性問題。在第二部分，將涉及一些最優(yōu)化ADO函數(shù)，并將它們的結(jié)果與調(diào)用VB COM對象執(zhí)行相同ADO函數(shù)的ASP頁面進(jìn)行比較。這些結(jié)果很讓人開眼界，甚至有些時(shí)候是很令人吃驚的。

　

    所有測試都是用Microsoft的Web應(yīng)用程序重點(diǎn)工具(WAST)來進(jìn)行的，這是一個(gè)免費(fèi)的工具，可以在這里找到。我用WAST創(chuàng)建了一個(gè)簡單的test 腳本，反復(fù)調(diào)用下面所描述的ASP頁面測試（每個(gè)超過70，000次）。反應(yīng)的時(shí)間基于平均最后字節(jié)總時(shí)間(TTLB), 也就是從最初請求的時(shí)間到工具從服務(wù)器接收最后一位數(shù)據(jù)的時(shí)間。我們的測試服務(wù)器是一個(gè)Pentium 166，內(nèi)存為196MB，客戶機(jī)為Pentium 450，內(nèi)存為256MB。你也許會想這些機(jī)器的性能并不算很高級，但是不要忘了，我們并不是要測試服務(wù)器的容量，我們只是要測試服務(wù)器每次處理一個(gè)頁面所用的時(shí)間。測試期間這些機(jī)器不做其它工作。WAST 測試腳本、測試報(bào)告以及所有的ASP測試頁面都包含在ZIP文件中，你可以自己進(jìn)行回顧和測試。 

將ASP生成的內(nèi)容寫入響應(yīng)流中最有效的方法是什么？
　　 使用ASP的一個(gè)最主要原因是在服務(wù)器上生成動態(tài)內(nèi)容。所以很明顯，我們測試的起點(diǎn)是確定將動態(tài)內(nèi)容發(fā)送到響應(yīng)流中的最適合的方式。在多種選擇中，有兩個(gè)是最基本的：一是使用內(nèi)聯(lián)ASP標(biāo)記，另一個(gè)是使用Response.Write 語句。

　　為測試這些選擇，我們創(chuàng)建了一個(gè)簡單的ASP頁面，其中定義了一些變量，然后將它們的值插入表格中。雖然這個(gè)頁面很簡單也不是很實(shí)用，但它允許我們分離并測試一些單獨(dú)的問題。

　　使用ASP內(nèi)聯(lián)標(biāo)記
　　第一個(gè)測試包括使用內(nèi)聯(lián)ASP標(biāo)記＜ %= x % ＞，其中x是一個(gè)已賦值的變量。到目前為止，這個(gè)方法是最容易執(zhí)行的，并且它使頁面的HTML部分保持一種易于閱讀和維護(hù)的格式。

＜ % OPTION EXPLICIT
　Dim FirstName
　Dim LastName
　Dim MiddleInitial
　Dim Address
　Dim City
　Dim State
　Dim PhoneNumber
　Dim FaxNumber
　Dim EMail
　Dim BirthDate
　FirstName = "John"
　MiddleInitial = "Q"
　LastName = "Public"
　Address = "100 Main Street"
　City = "New York"
　State = "NY"
　PhoneNumber = "1-212-555-1234"
　FaxNumber = "1-212-555-1234"
　EMail = "john@public.com"
　BirthDate = "1/1/1950"
　% ＞
?。?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 ＞Middle Initial:＜ /b ＞＜ /td ＞＜ td ＞＜ %= MiddleInitial % ＞＜ /td ＞＜ /tr ＞
?。?tr ＞＜ td ＞＜ b ＞Last Name:＜ /b ＞＜ /td ＞＜ td ＞＜ %= LastName % ＞＜ /td ＞＜ /tr ＞
　＜ tr ＞＜ td ＞＜ b ＞Address:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Address % ＞＜ /td ＞＜ /tr ＞
?。?tr ＞＜ td ＞＜ b ＞City:＜ /b ＞＜ /td ＞＜ td ＞＜ %= City % ＞＜ /td ＞＜ /tr ＞
　＜ tr ＞＜ td ＞＜ b ＞State:＜ /b ＞＜ /td ＞＜ td ＞＜ %= State % ＞＜ /td ＞＜ /tr ＞
?。?tr ＞＜ td ＞＜ b ＞Phone Number:＜ /b ＞＜ /td ＞＜ td ＞＜ %= PhoneNumber % ＞＜ /td ＞＜ /tr ＞
　＜ tr ＞＜ td ＞＜ b ＞Fax Number:＜ /b ＞＜ /td ＞＜ td ＞＜ %= FaxNumber % ＞＜ /td ＞＜ /tr ＞
?。?tr ＞＜ td ＞＜ b ＞EMail:＜ /b ＞＜ /td ＞＜ td ＞＜ %= EMail % ＞＜ /td ＞＜ /tr ＞
?。?tr ＞＜ td ＞＜ b ＞Birth Date:＜ /b ＞＜ /td ＞＜ td ＞＜ %= BirthDate % ＞＜ /td ＞＜ /tr ＞
　＜ /TABLE ＞
?。?/BODY ＞
　＜ /HTML ＞
　　/app1/response1.asp的完整代碼

　　以前的最佳（反應(yīng)速度） = 8.28 msec/page

　　在HTML的每一行使用Response.Write 語句

　　許多比較好的學(xué)習(xí)文檔建議避免使用前面的那種方法。其主要理由是，在輸出頁面和處理頁面施加反應(yīng)時(shí)間的過程中，如果web 服務(wù)器不得不在發(fā)送純HTML和處理腳本之間進(jìn)行轉(zhuǎn)換，就會發(fā)生一種被稱為上下文轉(zhuǎn)換的問題。大部分程序員一聽到這里，他們的第一反應(yīng)就是將原始的HTML的每一行都包裝在Response.Write函數(shù)中。

　　…
　　Response.Write("＜ html ＞")
　　Response.Write("＜ head ＞")
　　Response.Write(" ＜ title ＞Response Test＜ /title ＞")
　　Response.Write("＜ /head ＞")
　　Response.Write("＜ body ＞")
　　Response.Write("＜ h1 ＞Response Test＜ /h1 ＞")
　　Response.Write("＜ table ＞")
　　Response.Write("＜ tr ＞＜ td ＞＜ b ＞First Name:＜ /b ＞＜ /td ＞＜ td ＞" & FirstName & "＜ /td ＞＜ /tr ＞")
　　Response.Write("＜ tr ＞＜ td ＞＜ b ＞Middle Initial:＜ /b ＞＜ /td ＞＜ td ＞" & MiddleInitial & "＜ /td ＞＜ /tr ＞")
　　… <

　　/app1/response2.asp的片段

　　以前的最佳（反應(yīng)速度） = 8.28 msec/page

　　反應(yīng)時(shí)間 = 8.08 msec/page

　　差= -0.20 msec (減少 2.4%)

　　我們可以看到，使用這種方法與使用內(nèi)聯(lián)標(biāo)記的方法相比在性能上獲得的收益非常小，這也許是因?yàn)轫撁娼o服務(wù)器裝載了一大堆小的函數(shù)調(diào)用。這種方法最大的缺點(diǎn)是，由于現(xiàn)在HTML都嵌入腳本中，所以腳本代碼變得更加冗長，更加難以閱讀和維護(hù)。
　　使用包裝函數(shù)

　　當(dāng)我們試圖使用Response.Write 語句這種方法時(shí)，最令人灰心的發(fā)現(xiàn)可能就是Response.Write 函數(shù)不能在每行的結(jié)尾處放置一個(gè)CRLF 。因此，當(dāng)你從瀏覽器中閱讀源代碼時(shí)，本來布置得非常好的HTML，現(xiàn)在成了沒有結(jié)束的一行。我想，你的下一個(gè)發(fā)現(xiàn)可能會更令你恐怖：在Response 對象中沒有其姊妹函數(shù)Writeln 。所以，一個(gè)很明顯的反應(yīng)就是為Response.Write 函數(shù)創(chuàng)建一個(gè)包裝函數(shù)，以便給每一行都附加一個(gè)CRLF 。

　… 　　writeCR("＜ tr ＞＜ td ＞＜ b ＞First Name:＜ /b ＞＜ /td ＞＜ td ＞" & FirstName & "＜ /td ＞＜ /tr ＞")
　　…
　　SUB writeCR(str)
　　Response.Write(str & vbCRLF)
　　END SUB
　　/app1/response4.asp的片段
　　以前的最佳（反應(yīng)速度）= 8.08 msec/page
　　反應(yīng)時(shí)間= 10.11 msec/page
　　差 = +2.03 msec (增加 25.1%)
　　當(dāng)然，由于這種方法有效地使函數(shù)調(diào)用次數(shù)加倍，其對性能的影響也很明顯，因此要不惜一切代價(jià)避免。具有諷刺意味的是CRLF也向反應(yīng)流中為每行增加了2個(gè)字節(jié)，而這是瀏覽器不需要呈現(xiàn)到頁面上的。格式化良好的HTML所做的一切就是讓你的競爭者更容易閱讀你的HTML源代碼并理解你的設(shè)計(jì)。

　　將連續(xù)的Response.Write 連接到一個(gè)單獨(dú)語句中

　　不考慮我們前面用包裝函數(shù)進(jìn)行的測試，下一個(gè)合乎邏輯的步驟就是從單獨(dú)的Response.Write 語句中提取出所有的字符串，將它們連接到一個(gè)單獨(dú)語句中，這樣就減少了函數(shù)調(diào)用的次數(shù)，極大地提高了頁面的性能。

　　… 　　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 ＞")

　　/app1/response3.asp的片段

　　以前的最佳（反應(yīng)速度）= 8.08 msec/page

　　反應(yīng)時(shí)間 = 7.05 msec/page

　　差 = -1.03 msec (減少12.7%)

　　目前，這是最優(yōu)化的配置。

　　將連續(xù)的Response.Write 連接到一個(gè)單獨(dú)語句中，在每行結(jié)尾處增加一個(gè)CRLF

　　考慮到那些要求他們的源代碼從瀏覽器中看要很純粹的人，我用vbCRLF 常量在前面測試中每行的結(jié)尾處插入了一些回車，然后重新運(yùn)行?！　?br />

　　…
　　Response.Write("＜ html ＞" & vbCRLF & _
　　"＜ head ＞" & vbCRLF & _
　　" ＜ title ＞Response Test＜ /title ＞" & vbCRLF & _
　　"＜ /head ＞" & vbCRLF & _
　　…
　　/app1/response5.asp的片段

　　前面的最佳（反應(yīng)速度）= 7.05 msec/page

　　反應(yīng)時(shí)間= 7.63 msec/page

　　差 = +0.58 msec (增加 8.5%)
　　運(yùn)行的結(jié)果在性能上有一點(diǎn)降低，這也許是由于額外的串聯(lián)和增加的字符量。

　　回顧和觀測

　　從前面有關(guān)ASP輸出的測試中可以得出一些規(guī)則：

　　* 避免內(nèi)聯(lián)ASP的過多使用。

　　* 總是將連續(xù)Response.Write 語句連接進(jìn)一個(gè)單獨(dú)語句內(nèi)。

　　* 永遠(yuǎn)不要在Response.Write 周圍使用包裝函數(shù)來附加CRLF。

　　* 如果必須格式化HTML輸出，直接在Response.Write 語句內(nèi)附加CRLF

是否應(yīng)該開啟緩沖器？
　　通過腳本程序啟動緩沖器
　　 在ASP腳本的頂部包含Response.Buffer=True ，IIS就會將頁面的內(nèi)容緩存。

　?。?#160;% 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%)

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

　　通過服務(wù)器配置啟動緩沖器

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

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

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

　　回顧及觀測

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

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

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

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

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

　?。?#160;% 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%)
　　測試的結(jié)果是驚人的。雖然注釋幾乎相當(dāng)于文件本身的兩倍，但是它們的存在并沒有給反應(yīng)時(shí)間帶來很大的影響。所以說我們可以遵循以下規(guī)則：

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

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

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

　?。?#160;%@ 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%)
　　可以看到，包含了語言的聲明對性能有一個(gè)輕微的影響。因此：

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

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

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

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

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

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

　?。?#160;%@ 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%)

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

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

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

　　基準(zhǔn)值 = 5.57 msec/page
　　 反應(yīng)時(shí)間= 5.14 msec/page
　　 差= -0.43 msec (降低7.7%)
　　這是性能的又一個(gè)顯著提高。所以，我們的規(guī)則應(yīng)是：在不需要的情況下，總是在頁面或應(yīng)用程序的水平上關(guān)閉Session狀態(tài)。

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

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

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

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

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

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

　　將Response.Write 語句移入子程序

　　這個(gè)測試只是將Response.Write 語句移入一個(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)用給頁面帶來了額外的負(fù)擔(dān)。

　　將所有腳本移入子程序中

　　在這個(gè)測試中，Response.write 語句與變量聲明都移入一個(gè)子程序區(qū)中。

　?。?#160;% OPTION EXPLICIT v 　　 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è)頁面上，如果代碼要使用一次以上，就將代碼封入函數(shù)區(qū)。
　　 * 適當(dāng)時(shí)候，將變量聲明移到函數(shù)范圍內(nèi)。

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

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

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

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

　?。?#160;% OPTION EXPLICIT
　　 Dim FirstName
　 　 …
　　 Dim BirthDate
　　 FirstName = "John"
　　 …
　　 BirthDate = "1/1/1950"
　　 % ＞
　?。?#160;!-- #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 引用是在頁面頂部進(jìn)行的，在ASP腳本的適當(dāng)位置調(diào)用子程序。

　　＜ % OPTION EXPLICIT
　　 Dim FirstName
　　 …
　　 Dim BirthDate
　　 FirstName = "John"
　　 …
　　 BirthDate = "1/1/1950"
　　 CALL writeTable()
　　 % ＞
　?。?#160;!-- #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% 增加)

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

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

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

　?。?#160;% 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ò)誤句柄帶來了代價(jià)。我們可以提出以下建議：只有在會發(fā)生超出測試或控制能力之外的情況時(shí)才使用錯(cuò)誤句柄。一個(gè)最基本的例子就是使用存取其它資源，如ADO或FileSystem 對象的COM對象。

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

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

　?。?#160;%@ 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% 增加)

請留意以下規(guī)則：只有當(dāng)兩個(gè)或更多操作被作為一個(gè)單元執(zhí)行時(shí)，才使用處理上下文。