ASP開發人員為了在他們的設計專案中獲得更好的效能和可擴展性而不斷努力。幸運地是，有許多書籍和站點在這方面提供了很好的建議。但是這些建議的基礎都是從ASP平台工作的結構上所得出的結論，對實際獲得的性能的提高沒有量的測量。由於這些建議需要更加複雜的編碼過程並降低了編碼的可讀性，開發人員就只能在看不到實際運作效果的情況下，獨自衡量為了提高他們ASP應用程式的效能是否值得付出這些代價。
本文分為兩大部分，我將介紹一些效能測試結果，幫助開發人員來確定某一特定舉措是否不僅對將來的專案來說是值得的，並且能夠對原來的專案進行更新。在第一部分我將回顧一些ASP開發的基礎性問題。在第二部分，將涉及一些最優化ADO函數，並將它們的結果與呼叫VB COM物件執行相同ADO函數的ASP頁面進行比較。這些結果很讓人開眼界，甚至有些時候是很令人驚訝的。
在本文中，我們將回答以下問題：
* 將ASP產生的內容寫入回應流中最有效的方法是什麼？
* 是否應該開啟緩衝器？
* 是否應該考慮在ASP程式碼中增加註解？
* 是否應該為頁面明確地設定預設語言？
* 如果不需要，是否應該關閉Session 狀態？
* 是否應該把腳本邏輯放在子程式和函數區？
* 使用包含文件有什麼影響？
* 執行錯誤處理時會施加什麼樣的負載？
* 設定一個上下文處理是否對效能有影響？
所有測試都是用Microsoft的Web應用程式重點工具(WAST)來進行的，這是一個免費的工具，可以在這裡找到。我用WAST建立了一個簡單的test 腳本，重複呼叫下面所描述的ASP頁面測試（每個超過70，000次）。反應的時間是基於平均最後位元組總時間(TTLB), 也就是從最初請求的時間到工具從伺服器接收最後一位資料的時間。我們的測試伺服器是一個Pentium 166，記憶體為196MB，客戶機為Pentium 450，記憶體為256MB。你也許會想這些機器的效能並不算很高級，但是不要忘了，我們並不是要測試伺服器的容量，我們只是要測試伺服器每次處理一個頁面所用的時間。測試期間這些機器不做其它工作。 WAST 測試腳本、測試報告以及所有的ASP測試頁面都包含在ZIP檔案中，你可以自己進行回顧和測試。
將ASP產生的內容寫入回應流中最有效的方法是什麼？
使用ASP的一個最主要原因是在伺服器上產生動態內容。所以很明顯，我們測試的起點是確定將動態內容傳送到回應流中的最適合的方式。在多種選擇中，有兩個是最基本的：一是使用內聯ASP標記，另一個是使用Response.Write 語句。
為測試這些選擇，我們建立了一個簡單的ASP頁面，其中定義了一些變量，然後將它們的值插入表格中。雖然這個頁面很簡單也不是很實用，但它允許我們分開並測試一些單獨的問題。
使用ASP內聯標記
第一個測試包括使用內聯ASP標記＜ %= x % ＞，其中x是一個已賦值的變數。到目前為止，這個方法是最容易執行的，而且它使頁面的HTML部分保持一種易於閱讀和維護的格式。
＜ % 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 = [email protected]
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 td ＞＜ %= FirstName % ＞＜ /td ＞＜ /tr
＜ tr ＞＜ td ＞＜ b ＞Middle Initial:＜ /b ＞＜ /td ＞＜ td ＞＜ %= MiddleInitial % ＞＜ /td ＞＜ %= MiddleInitial % ＞＜ /tdtd ＜
＜ tr ＞＜ td ＞＜ b ＞Last Name:＜ /b ＞＜ /td ＞＜ td ＞＜ %= LastName % ＞＜ /td td ＞＜ %= LastName % ＞＜ /td
＜ tr ＞＜ td ＞＜ b ＞Address:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Address % ＞＜ /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 ＞＜ %= PhoneNumber % ＞＜ /td ＞＜ /
＜ tr ＞＜ td ＞＜ b ＞Fax Number:＜ /b ＞＜ /td ＞＜ td ＞＜ %= FaxNumber % ＞＜ /td ＞＜ %= FaxNumber % ＞＜ /td /td /
＜ tr ＞＜ td ＞＜ b ＞EMail:＜ /b ＞＜ /td ＞＜ td ＞＜ %= EMail % ＞＜ /td ＞＜ / ＞＜
＜ tr ＞＜ td ＞＜ b ＞Birth Date:＜ /b ＞＜ /td ＞＜ td ＞＜ %= BirthDate % ＞＜ /td ＞＜ %= BirthDate % ＞＜ /td /td /
＜ /TABLE ＞
＜ /BODY ＞
＜ /HTML ＞
/app1/response1.asp的完整程式碼
以前的最佳（反應速度） = 8.28 msec/page
在HTML的每一行使用Response.Write 語句
許多比較好的學習文件建議避免使用前面的那種方法。其主要理由是，在輸出頁面和處理頁面施加反應時間的過程中，如果web 伺服器必須在發送純HTML和處理腳本之間進行轉換，就會發生一種稱為上下文轉換的問題。大部分程式設計師一聽到這裡，他們的第一個反應就是將原始的HTML的每一行都包裝在Response.Write函數中。
…
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 ＞＜ / ＞＜ ＞＜)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Middle Initial:＜ /b ＞＜ /td ＞＜ td ＞ & MiddleInitial & ＜ /td ＞＜ td ＞ & MiddleInitial & ＜ /td ＞＜ /tr
… <
/app1/response2.asp的片段
以前的最佳（反應速度） = 8.28 msec/page
反應時間= 8.08 msec/page
差= -0.20 msec (減少2.4%)
我們可以看到，使用這種方法與使用內聯標記的方法相比在效能上獲得的收益非常小，這也許是因為頁面為伺服器裝載了一大堆小的函數呼叫。這種方法最大的缺點是，由於現在HTML都嵌入腳本中，所以腳本程式碼變得更冗長，更難以閱讀和維護。
使用包裝函數
當我們試圖使用Response.Write 語句這種方法時，最令人灰心的發現可能就是Response.Write 函數不能在每行的結尾處放置一個CRLF 。因此，當你從瀏覽器中閱讀原始程式碼時，本來佈置得非常好的HTML，現在成了沒有結束的一行。我想，你的下一個發現可能會更令你恐怖：在Response 物件中沒有其姊妹函數Writeln 。所以，一個很明顯的反應就是為Response.Write 函數建立一個包裝函數，以便給每一行都附加一個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的片段
以前的最佳（反應速度）= 8.08 msec/page
反應時間= 10.11 msec/page
差= +2.03 msec (增加25.1%)
當然，由於這種方法有效地使函數呼叫次數加倍，其對效能的影響也很明顯，因此不惜一切代價避免。諷刺的是CRLF也為反應流中為每行增加了2個位元組，而這是瀏覽器不需要呈現到頁面上的。格式化良好的HTML所做的一切就是讓你的競爭對手更容易閱讀你的HTML原始碼並理解你的設計。
將連續的Response.Write 連接到一個單獨語句中
不考慮我們前面用包裝函數進行的測試，下一個合乎邏輯的步驟就是從單獨的Response.Write 語句中提取出所有的字串，將它們連接到一個單獨語句中，這樣就減少了函數呼叫的次數，大大提高了頁面的效能。
…
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 td ＞ & FirstName & ＜ /td ＞＜ /tr td ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞Birth Date:＜ /b ＞＜ /td ＞＜ td ＞ & BirthDate & ＜ /td ＞＜ td ＞ & BirthDate & ＜ /td ＞＜ /tr ＞ _
＜ /table ＞ & _
＜ /body ＞ & _
＜ /html ＞)
/app1/response3.asp的片段
以前的最佳（反應速度）= 8.08 msec/page
反應時間= 7.05 msec/page
差= -1.03 msec (減少12.7%)
目前，這是最優化的配置。
將連續的Response.Write 連接到一個單獨語句中，在每行結尾處增加一個CRLF
考慮到那些要求他們的原始程式碼從瀏覽器中看要很純粹的人，我用vbCRLF 常數在前面測試中每行的結尾處插入了一些回車，然後重新運行。
…
Response.Write(＜ html ＞ & vbCRLF & _
＜ head ＞ & vbCRLF & _
＜ title ＞Response Test＜ /title ＞ & vbCRLF & _
＜ /head ＞ & vbCRLF & _
…
/app1/response5.asp的片段
前面的最佳（反應速度）= 7.05 msec/page
反應時間= 7.63 msec/page
差= +0.58 msec (增加8.5%)
運行的結果在性能上有一點降低，這也許是由於額外的串聯和增加的字元量。
回顧和觀測
從前面有關ASP輸出的測試可以得到一些規則：
* 避免內聯ASP的過度使用。
* 總是將連續Response.Write 語句連接進一個單獨語句內。
* 永遠不要在Response.Write 周圍使用包裝函數來附加CRLF。
* 若必須格式化HTML輸出，直接在Response.Write 語句內附加CRLF。
是否應該開啟緩衝器？
透過腳本程式啟動緩衝器
在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 ＞＜ 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 td ＞ & FirstName & ＜ /td ＞＜ /tr td ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞Birth Date:＜ /b ＞＜ /td ＞＜ td ＞ & BirthDate & ＜ /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% 增加)
啊！這真實最戲劇性的結果。所以請留意以下規則：只有當兩個或更多操作被作為一個單元執行時，才使用處理上下文。
結論
本文第一部分的重要之處在於許多小事的累積。為了強調這個問題，我設定了最後一個測試，在其中進行了我們以前曾經測試過的看來無所謂但實際上有壞影響的所有操作。我包含了許多Response.Write 宣告、關閉了緩衝器、設定了預設語言、去掉了Option Explicit 引用並初始化了錯誤句柄。
＜ %@ LANGUAGE=VBSCRIPT % ＞
＜ %
On Error Resume Next
FirstName = John
…
BirthDate = 1/1/1950
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 ＞Birth Date:＜ /b ＞＜ /td ＞＜ td ＞ &_
BirthDate & ＜ /td ＞＜ /tr ＞)
Response.Write(＜ /table ＞)
Response.Write(＜ /body ＞)
Response.Write(＜ /html ＞)
% ＞
/app2/final_1.asp片段
基準值= 5.57 msec/page
反應時間= 8.85 msec/page
差= +3.28 msec (58.9% 增加)
聽起來可能很明顯，但是理解更重要，那就是我們放置在頁面上的程式碼會對效能有影響。頁面上的小變化有時會大大增加反應時間。
規則概括
* 避免內聯ASP的過度使用。
* 總是將連續Response.Write 語句連接進一個單獨語句內。
* 永遠不要在Response.Write 周圍使用包裝函數以附加CRLF。
* 若必須格式化HTML輸出，直接在Response.Write 語句內附加CRLF。
* 總是透過伺服器設定開啟緩衝器。
* 只要使用適度，ASP註釋對效能的影響很小或根本沒有影響。
* 設定伺服器的預設語言配置以與網站上使用的語言相符。
* 除非你使用非預設語言，不要設定語言宣告。
* 在VBScript中總是使用Option explicit 。
* 在不需要的情況下，總是在頁面或應用程式的水平上關閉Session狀態。
* 只有當程式碼在頁面之間共用時才使用Include 檔案。
* 在一個頁面上，如果程式碼要使用一次以上，就將程式碼封入函數區。
* 適當時候，將變數宣告移到函數範圍內。
* 只有會發生超出測試或控制能力之外的情況時才使用錯誤句柄。
* 只有當兩個或更多操作被作為一個單元執行時，才使用上下文處理。
現在回顧一下，有許多問題可以作為普遍性的方針：
* 避免冗餘--不要設定那些預設狀態下已經設定的屬性。
* 限制函數呼叫的次數。
* 縮小程式碼的範圍。