效能 ASP開發人員為了在他們的設計項目中獲得更好的效能和可擴充性而不斷努力。幸運地是，有許多書籍和網站在這方面提供了很好的建議。但是這些建議的基礎都是從ASP平台工作的結構上所得出的結論，對實際獲得的效能的提高沒有量的測量。由於這些建議需要更加複雜的編碼過程並降低了編碼的可讀性，開發人員就只能在看不到實際運行效果的情況下，獨自衡量為了提高他們ASP應用程式的效能是否值得付出這些代價。
本文分為兩大部分，我將介紹一些效能測試結果，協助開發人員來確定某一特定舉措是否不僅對將來的項目來說是值得的，並且能夠對原來的項目進行更新。在第一部分我將回顧一些ASP開發的基礎性問題。在第二部分，將涉及一些最佳化ADO函數，並將它們的結果與調用VB COM對象執行相同ADO函數的ASP頁面進行比較。這些結果很讓人開眼界，甚至有些時候是很令人吃驚的。
在本文中，我們將回答以下問題：
* 將ASP產生的內容寫入響應流中最有效方法是什嗎？
* 是否應該開啟緩衝器？
* 是否應該考慮向ASP代碼中增加註釋？
* 是否應該為頁面明確地設定預設語言？
* 如果不需要，是否應該關閉Session 狀態？
* 是否應該把指令碼邏輯放在子程式和函數區中？
* 使用包含檔案有什麼影響？
* 執行錯誤處理時會施加什麼樣的負載？
* 設定一個上下文處理是否對效能有影響？
所有測試都是用Microsoft的Web應用程式重點工具(WAST)來進行的，這是一個免費的工具，可以在這裡(http://webtool.rte.microsoft.com/)找到。我用WAST建立了一個簡單的test 指令碼，反覆調用下面所描述的ASP頁面測試（每個超過70，000次）。反應的時間基於平均最後位元組總時間(TTLB), 也就是從最初請求的時間到工具從伺服器接收最後一位元據的時間。我們的測試伺服器是一個Pentium 166，記憶體為196MB，客戶機為Pentium 450，記憶體為256MB。你也許會想這些機器的效能並不算很進階，但是不要忘了，我們並不是要測試伺服器的容量，我們只是要測試伺服器每次處理一個頁面所用的時間。測試期間這些機器不做其它工作。WAST 測試指令碼、測試報告以及所有的ASP測試頁面都包含在ZIP檔案(http://www.asptoday.com/articles/images/20000113.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 = "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的完整代碼
以前的最佳（反應速度） = 8.28 msec/page
在HTML的每一行使用Response.Write 語句
許多比較好的學習文檔建議避免使用前面的那種方法。其主要理由是，在輸出頁面和處理頁面施加反應時間的過程中，如果網頁伺服器不得不在發送純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 >< /
tr >"
