ASP 能快速執行你的動態網頁，但你還可以通過緊縮代碼和數據庫連接以使它們執行更快。這是一篇關於怎樣精簡代碼和Asp 特徵以獲得最快執行速度的詳細文章。對於一個急燥的用戶來說，任何在按下用戶按鈕到結果出現在它們的屏幕之間的延遲可能意味着它們會轉到瀏覽其它的站點？假如你的是商業站點，這有可能意味着失去潛在的銷售。
我們沒有任何辦法控制用戶的帶寬，但我們的確能通過優化Asp 站點來獲得最佳的性能。大部分潛在性能的提升是通過系統改變而不是緊縮代碼，一個不合適的想法是，一旦遇到系統效率問題，就向系統管理者提意見要其升級系統。
首先，哪個因素可能影響Asp的性能？很不幸，有很多因素？下面這些只是其中的一部分：
可用帶寬
服務器上的處理器和其它硬件的速度
在服務器上運行的其它程序(比如象那些OpenGL屏幕保護程序！)
數據庫連接模式，連接池，數據庫系統本身(比如Oracle優於Sql Server，Sql server優於Access)
所使用的語言
存儲過程優於行式Sql語句
使用編譯組件而不是VB或JavaScript，好的Asp編程經驗，比如錯誤處理等
一些以上的因素可能已經被有IIS 知識經驗的開發者普遍留意到了，但其它的可能對於他們來說是十分複雜的問題。在這篇文章裏， 將試着解釋所有影響Asp性能的每個因素，讓我們看一看那些在我們刮鬍子的幾毫秒內就能做到的主要事情。
ASP腳本大小
你是腳本頁(還有其它頁面)是不是比必須的長度要長？這是一開始執行就會降低Asp 性能的東西。ASP 腳本在用來獲取信息和格式化輸出的時候是十分有用的，但腳本也是逐行解釋執行，所以你的腳本越長，執行它的時間也就越長。
如果你的腳本很龐大，怎麼做才能減少腳本的長度呢？這裏有幾點建議：
你可以將它們轉換成服務器端組件，也就是說，做成VB動態鏈接庫DLL或者通過先進的Windows編程語言或適當的COM 接口語言將它轉換成未編譯組件？並且在服務器端註冊它們。有關的快速指南可以在
http://www.webdevelopersjournal.com/articles/activex_for_asp.html找到。對一個寫得好的ActiveX 組件進行編譯不但能大幅度提高性能，還可以保護你的軟件(腳本)，尤其當你將你的Asp站點發布在第三方主機上的時候。
因爲腳本是逐行解釋執行的，所以剔除多餘的腳本或建立更高效率的腳本能夠改進性能。如果你在單個Asp 文件中有數百行的代碼，可能這樣做你能很好地劃分使用者，買賣和數據服務。事實上，如果你這樣做，可能會找出一些冗餘的代碼：如果你需要輸出幾個表格，你可以編寫一個通用函數來輸出一個表格，只是多次調用它。
在講述Asp 腳本的大小問題的時候，不得不提及包含文件的大小。當你使用一個包含文件的時候，整個包含文件被裝入，當包含文件被包含的時候，相當於在Asp 文件本身寫下那部分代碼。因此，如果你在一個冗長的包含文件裏定義了很多通用的方法和定義，要明白到在你包含該文件的時候，不管你要不要用到裏面的每個方法和定義，它都是被整個裝入的。ASP 緩存全部的展開代碼，這會降低查找效率在這種情況下，包含文件必須被分割成更小的，模塊化的文件。也要明白到包含文件被服務器視爲單獨的頁面請求，使用太多的包含文件會影響下載時間。
每個人都這樣做？當我們輸出表格的時候，我們會在ASP 和HTML代碼間轉換，而這是一個不好的習慣。例如：
Session狀態
無庸置疑地，在Asp中能夠通過Session維持某個狀態的能力是十分強大的特色。然而，它會影響你的性能。明顯地，你的站點的可伸縮性性變成了另一個問題，如果限制Session的使用的話。然而，session會爲每個用戶消耗服務器資源。
如果你不使用session 變量，或事實上你不必使用？使用隱藏表單域，在數據庫中保存數據，查詢字符串是不是其中的竅門？所以你應該禁止Session狀態。你可以使用下面的聲明禁止使用session：
@EnableSessionState = False
這樣，ASP將不再檢查session信息。
如果你不得不依賴於session狀態，應該避免在session對象中存放大量的數據。IIS中的session在客戶端的HTTP cookie可用的時候就會保持，導致被session佔用的內存在session 終止或超時前一直被佔用。這樣，如果很多用戶同時使用你的程序的時候，你的服務器資源可能會耗盡。
數據庫訪問
數據庫訪問是必須的麻煩？訪問數據庫將會激烈地減慢你的程序，但很顯然，如果沒有數據庫，很多站點將變得毫無價值可言。但通過存儲過程訪問數據庫來代替使用嵌入式Sql 語句，你可以提升潛在的性能。通過使用存儲過程和ActiveX Data Objects (ADO)，它們亦同樣擁有良好的靈活性。儘可能從存儲過程來輸出數據。
確認你的數據庫具有索引，因爲這樣能直接提高你的程序的效率。同樣，儘量在你的數據庫服務器運行更新統計(Update Statistics) 以幫助追蹤你的數據分發，這樣，你的數據庫就能夠基於這些信息來改造查詢執行。注意一些數據庫比如MS Access，是不是真正能在企業級程序中接受？SQL Sever 7.0或者Oracle是一個更好的賭注。
讓SQL象它被設計的那樣工作，它能count(統計)，連接(join)，排序(sort)和group 數據。當你能夠寫出一個查詢語句來做這些東西的時候，就不要自己用其它語言來實現。
下面是一個統計所有列的最簡單的語法：
OLEDB 介於ODBC層和應用程序之間。在你的ASP 頁面中，ADO介於ODEDB之上的“應用程序”。你的ADO調用首先被送到OLEDB，接着被送到ODBC層。然而，你可以直接連接到OLEDB 層，並且如果你這樣做的話，你就能看到服務器端性能的提高。然而，怎樣直接連接到OLEDB？
如果你使用SQLServer 7，使用下面的連接代碼連接數據庫：
現在你可能會覺得有點奇怪：我們在這個新的連接方法中的要點是什麼呢？爲什麼不使用標準DSN-less/System DSN途徑？呵，根據Wrox 在他的著作《ADO 2.0 Programmer's Reference》中測試的結果表明，如果你使用OLEDB連接和DSN或者DSN-less連接方法比較，你會發現有下面的改進：
性能對比：
SQL Access
OLEDBDSNOLEDBDSN
連接時間：18?82?連接時間：62?99
查詢1,000條記錄時間：29005400查詢1,000條記錄時間： 100950
註釋：這個結果在Wrox的《ADO 2.0 Programmer's Reference》一書的第232和233頁可以查到。時間的單位是毫秒，查詢1,000記錄時間是通過服務器端遊標計算出來的(當使用客戶端遊標的時候，OLEDB與DSN記錄集的性能之間的差別不大)。
ASP譯碼問題：
儘可能在客戶端確認用戶輸入來減少HTTP來回請求的數量。如果瀏覽器有支持JavaScript或其它腳本的能力，使用它們的力量以釋放更多的服務器資源。
下面的VBScript運行於客戶端瀏覽器，在提交到你的服務器之前，用來驗證用戶信息：
如果你需要引用不一定要用到的對象，那麼最好使用＜OBJECT＞標記而不是用 Server.CreateObject方法。 使用Server.CreateObject引起對象立即被建立，反之，＜OBJECT＞標記則不會這樣立即建立對象如果使用＜object＞定義後不使用該對象，你不會浪費資源。
例如：下面的例子是一個使用＜OBJECT＞標記建立一個application-scope廣告輪 Ad Rotator對象實
例：
＜OBJECT runat=server scope=Application id=MyAds progid="MSWC.AdRotator"＞
＜/OBJECT＞
在存儲該Ad Rotator對象進Application後，你可以在任何程序的頁面中用下面的語法訪問該對象
這是一個好習慣，it may trap typos, 這樣更快。
除非你真正需要使用，否而不要使用Server.MapPath方法。如果你知道真實路徑就使用真實路徑。使用MapPath需要IIS找回現時服務器路徑，這意味着得向服務器發一個特殊的請求，也就意味着降低了性能。另一個方法是將路徑存放到局部變量中，在需要的時候使用，這樣就不需要服務器多次查找。
檢查你自己是怎麼做的
你可以通過工具來測量你的系統性能，比如系統性能監視器，NetMon和PerfMon。測試web性能可以用WCAT (Web Capacity Analysis Tool)。使用WCAT，你可以測試你的IIS服務器和網絡配置響應各種各樣的客戶請求，數據或HTML頁面的能力。這些測試結果能夠被用來作爲優化你的服務器和網絡配置的指導。WCAT是專門設計用來估計Windows 2000中的因特網服務(或Windows NT)和IIS 能響應的客戶工作量
(仿真)。爲了得到更多的信息，請參閱IIS Resource Kit(資源工具包)。那裏也有冗長的WCAT用戶指南在MSDN在線Web sorkshop站點裏面有一個下載鏈接。如果你認真對待你的Asp 性能的話，務必取得該工具。
力求最優化應用程序性能，你的web 應用程序會運行更加順暢。如果不是真正需要，就不要影響服務器的性能。
摘要：
上面介紹了有關ASP性能的資料，有很多因素影響Asp的性能，這裏只討論了其中的一部分。作爲最終的想法，不要認爲你能夠處理好所有的因素，你的ASP 性能還是有必要提高的。你發佈的每個應用程序必須個別進行考慮，所有以上的技巧並不是適合每個Asp程序。
我們沒有任何辦法控制用戶的帶寬，但我們的確能通過優化Asp 站點來獲得最佳的性能。大部分潛在性能的提升是通過系統改變而不是緊縮代碼，一個不合適的想法是，一旦遇到系統效率問題，就向系統管理者提意見要其升級系統。
首先，哪個因素可能影響Asp的性能？很不幸，有很多因素？下面這些只是其中的一部分：
可用帶寬
服務器上的處理器和其它硬件的速度
在服務器上運行的其它程序(比如象那些OpenGL屏幕保護程序！)
數據庫連接模式，連接池，數據庫系統本身(比如Oracle優於Sql Server，Sql server優於Access)
所使用的語言
存儲過程優於行式Sql語句
使用編譯組件而不是VB或JavaScript，好的Asp編程經驗，比如錯誤處理等
一些以上的因素可能已經被有IIS 知識經驗的開發者普遍留意到了，但其它的可能對於他們來說是十分複雜的問題。在這篇文章裏， 將試着解釋所有影響Asp性能的每個因素，讓我們看一看那些在我們刮鬍子的幾毫秒內就能做到的主要事情。
ASP腳本大小
你是腳本頁(還有其它頁面)是不是比必須的長度要長？這是一開始執行就會降低Asp 性能的東西。ASP 腳本在用來獲取信息和格式化輸出的時候是十分有用的，但腳本也是逐行解釋執行，所以你的腳本越長，執行它的時間也就越長。
如果你的腳本很龐大，怎麼做才能減少腳本的長度呢？這裏有幾點建議：
你可以將它們轉換成服務器端組件，也就是說，做成VB動態鏈接庫DLL或者通過先進的Windows編程語言或適當的COM 接口語言將它轉換成未編譯組件？並且在服務器端註冊它們。有關的快速指南可以在
http://www.webdevelopersjournal.com/articles/activex_for_asp.html找到。對一個寫得好的ActiveX 組件進行編譯不但能大幅度提高性能，還可以保護你的軟件(腳本)，尤其當你將你的Asp站點發布在第三方主機上的時候。
因爲腳本是逐行解釋執行的，所以剔除多餘的腳本或建立更高效率的腳本能夠改進性能。如果你在單個Asp 文件中有數百行的代碼，可能這樣做你能很好地劃分使用者，買賣和數據服務。事實上，如果你這樣做，可能會找出一些冗餘的代碼：如果你需要輸出幾個表格，你可以編寫一個通用函數來輸出一個表格，只是多次調用它。
在講述Asp 腳本的大小問題的時候，不得不提及包含文件的大小。當你使用一個包含文件的時候，整個包含文件被裝入，當包含文件被包含的時候，相當於在Asp 文件本身寫下那部分代碼。因此，如果你在一個冗長的包含文件裏定義了很多通用的方法和定義，要明白到在你包含該文件的時候，不管你要不要用到裏面的每個方法和定義，它都是被整個裝入的。ASP 緩存全部的展開代碼，這會降低查找效率在這種情況下，包含文件必須被分割成更小的，模塊化的文件。也要明白到包含文件被服務器視爲單獨的頁面請求，使用太多的包含文件會影響下載時間。
＜!-- #include file="Header.asp" --＞
＜!-- #include file="Footer.asp" --＞
＜SCRIPT language="vbscript" runat="server"＞
Sub Main()
WriteHeader
WriteBody
WriteFooter
End Sub
Sub WriteBody()
...
End Sub
Main?'調用過程Main
＜/SCRIPT＞
假如你的腳本冗長的話，請使用Response.IsClientConnected。這意味着在客戶端不再連接到服務器的時候，你的服務器CPU能避免循環等待。＜%
'檢查客戶端是否仍在連接
If Not Response.IsClientConnected Then
'仍然連接着，處理程序
Else
'斷開
End If
%＞
Interspersing ASP and HTML每個人都這樣做？當我們輸出表格的時候，我們會在ASP 和HTML代碼間轉換，而這是一個不好的習慣。例如：
＜HTML＞
＜BODY＞
＜%
Set MyConn = Server.CreateObject("ADODB.Connection")
MdbFilePath = Server.MapPath("sample.mdb")
MyConn.Open "Driver={Microsoft Access Driver (*.mdb)}; DBQ=" & MdbFilePath & ";"
SQL_query = "SELECT * FROM Friends"
Set RS = MyConn.Execute(SQL_query)
WHILE NOT RS.EOF
%＞
＜LI＞＜%=RS("Name")%＞: ＜A HREF=""＞Homepage＜/A＞
＜%
RS.MoveNext
WEND
%＞
＜/BODY＞
＜/HTML＞
另一個普遍的例子是使用IF語句的時候：＜%
If Not Session("DBOpen") Then
%＞
＜H1＞Database not connected＜/H1＞
＜%
Else
%＞
＜H1＞Database open＜/H1＞
＜%
End If
%＞
在這些情況下，腳本性能能通過將服務器端腳本寫到一起來，而用Response.write產生Html代碼來提高性能。比如：＜%
If not Session ("DBOpen") Then
Response.Write "＜H1＞Database not connected＜/H1＞"
Else
Response.Write "＜H1＞Database open＜/H1＞"
End If
%＞
在大的腳本和很多腳本的情況下，你將能看到性能的提高。注意這裏儘量避免了使用＜%標記，這樣就能提高性能，ASP不需在執行腳本的時候計算字符的Ascii碼。Session狀態
無庸置疑地，在Asp中能夠通過Session維持某個狀態的能力是十分強大的特色。然而，它會影響你的性能。明顯地，你的站點的可伸縮性性變成了另一個問題，如果限制Session的使用的話。然而，session會爲每個用戶消耗服務器資源。
如果你不使用session 變量，或事實上你不必使用？使用隱藏表單域，在數據庫中保存數據，查詢字符串是不是其中的竅門？所以你應該禁止Session狀態。你可以使用下面的聲明禁止使用session：
@EnableSessionState = False
這樣，ASP將不再檢查session信息。
如果你不得不依賴於session狀態，應該避免在session對象中存放大量的數據。IIS中的session在客戶端的HTTP cookie可用的時候就會保持，導致被session佔用的內存在session 終止或超時前一直被佔用。這樣，如果很多用戶同時使用你的程序的時候，你的服務器資源可能會耗盡。
數據庫訪問
數據庫訪問是必須的麻煩？訪問數據庫將會激烈地減慢你的程序，但很顯然，如果沒有數據庫，很多站點將變得毫無價值可言。但通過存儲過程訪問數據庫來代替使用嵌入式Sql 語句，你可以提升潛在的性能。通過使用存儲過程和ActiveX Data Objects (ADO)，它們亦同樣擁有良好的靈活性。儘可能從存儲過程來輸出數據。
確認你的數據庫具有索引，因爲這樣能直接提高你的程序的效率。同樣，儘量在你的數據庫服務器運行更新統計(Update Statistics) 以幫助追蹤你的數據分發，這樣，你的數據庫就能夠基於這些信息來改造查詢執行。注意一些數據庫比如MS Access，是不是真正能在企業級程序中接受？SQL Sever 7.0或者Oracle是一個更好的賭注。
讓SQL象它被設計的那樣工作，它能count(統計)，連接(join)，排序(sort)和group 數據。當你能夠寫出一個查詢語句來做這些東西的時候，就不要自己用其它語言來實現。
下面是一個統計所有列的最簡單的語法：
SELECT count(*) FROM publishers WHERE state='NY'
如果你統計一個指定的列，你必須使用group by語句來分組該列，否則它不會工作：SELECT count(city),city FROM publishers GROUP BY city
分類返回的數據：SELECT * FROM TableName WHERE FieldName＞50 OR FieldName＜100 ORDER BY FieldName2, Field Name3
使用Odbc還是文件DSN連接數據庫？使用快速的OLEDB Provider技術連接你的數據庫而不是使用DSN連接。不再需要懇求你的ISP(或數據庫管理員/網管)爲你建立一個系統DSN，當你移走Web文件的時候，亦不需要改變配置。OLEDB 介於ODBC層和應用程序之間。在你的ASP 頁面中，ADO介於ODEDB之上的“應用程序”。你的ADO調用首先被送到OLEDB，接着被送到ODBC層。然而，你可以直接連接到OLEDB 層，並且如果你這樣做的話，你就能看到服務器端性能的提高。然而，怎樣直接連接到OLEDB？
如果你使用SQLServer 7，使用下面的連接代碼連接數據庫：
strConnString = "DSN='';DRIVER={SQL SERVER};" & _
"UID=myuid;PWD=mypwd;" & _
"DATABASE=MyDb;SERVER=MyServer;"
最重要的參數是DRIVER=部分。如果你要繞過ODBC而使用通過使用OLEDB 連接SQL Server(這是更快的連接)，請使用下面的語法：strConnString ="Provider=SQLOLEDB.1;Password=mypassword;" & _
"Persist Security Info=True;User ID=myuid;" & _
"Initial Catalog=mydbname;" & _
"Data Source=myserver;Connect Timeout=15"
有什麼不對的地方嗎？現在你可能會覺得有點奇怪：我們在這個新的連接方法中的要點是什麼呢？爲什麼不使用標準DSN-less/System DSN途徑？呵，根據Wrox 在他的著作《ADO 2.0 Programmer's Reference》中測試的結果表明，如果你使用OLEDB連接和DSN或者DSN-less連接方法比較，你會發現有下面的改進：
性能對比：
SQL Access
OLEDBDSNOLEDBDSN
連接時間：18?82?連接時間：62?99
查詢1,000條記錄時間：29005400查詢1,000條記錄時間： 100950
註釋：這個結果在Wrox的《ADO 2.0 Programmer's Reference》一書的第232和233頁可以查到。時間的單位是毫秒，查詢1,000記錄時間是通過服務器端遊標計算出來的(當使用客戶端遊標的時候，OLEDB與DSN記錄集的性能之間的差別不大)。
ASP譯碼問題：
儘可能在客戶端確認用戶輸入來減少HTTP來回請求的數量。如果瀏覽器有支持JavaScript或其它腳本的能力，使用它們的力量以釋放更多的服務器資源。
下面的VBScript運行於客戶端瀏覽器，在提交到你的服務器之前，用來驗證用戶信息：
＜SCRIPT LANGUAGE="VBScript"＞
＜!--
Sub btnEnter_onClick
Dim TheForm
Set TheForm = Document.MyForm
If IsNumeric(TheForm.Age.Value) Then
TheForm.submit
Else
Msgbox "Please enter a numerical age."
End if
End Sub
//--＞
＜/SCRIPT＞
＜FORMmethod="POST" name=MyFormaction="myfile.asp"＞? Name: ＜INPUT typr="text" name="Name"＞
Age: ＜INPUT type="text" name="Age"＞
＜INPUT type="button" name="btnEnter"value="Enter"＞
＜/FORM＞
使用局部變量，避免使用全局變量。局部變量比全局變量更快地被Asp 腳本引擎存取，因爲不需搜索整個名稱域。避免改變數組定義。在第一次初始化的時候就簡單分配足夠的大小效率更高。在這種情況下，你可能會浪費一些內存，但你獲得了速度的優勢。在服務器負載重的時候這個技術是顯然易見有效的。如果你需要引用不一定要用到的對象，那麼最好使用＜OBJECT＞標記而不是用 Server.CreateObject方法。 使用Server.CreateObject引起對象立即被建立，反之，＜OBJECT＞標記則不會這樣立即建立對象如果使用＜object＞定義後不使用該對象，你不會浪費資源。
例如：下面的例子是一個使用＜OBJECT＞標記建立一個application-scope廣告輪 Ad Rotator對象實
例：
＜OBJECT runat=server scope=Application id=MyAds progid="MSWC.AdRotator"＞
＜/OBJECT＞
在存儲該Ad Rotator對象進Application後，你可以在任何程序的頁面中用下面的語法訪問該對象
＜%=MyAds.GetAdvertisement("CustomerAds.txt") %＞
打開'Option Explicit'開關。在VB和VBScript 中，你可以在沒有顯式聲明的情況下使用變量。但打開這個選項可以鑑別用定義變量，這樣可以很好地書寫變量，並能幫助提高性能。未定義的局部變量會變慢，因爲在建立它之前，名稱空間必須被搜遍後才知道變量是否存在。擺脫它，使每個變量清楚地定義(先定義後使用)。這是一個好習慣，it may trap typos, 這樣更快。
除非你真正需要使用，否而不要使用Server.MapPath方法。如果你知道真實路徑就使用真實路徑。使用MapPath需要IIS找回現時服務器路徑，這意味着得向服務器發一個特殊的請求，也就意味着降低了性能。另一個方法是將路徑存放到局部變量中，在需要的時候使用，這樣就不需要服務器多次查找。
檢查你自己是怎麼做的
你可以通過工具來測量你的系統性能，比如系統性能監視器，NetMon和PerfMon。測試web性能可以用WCAT (Web Capacity Analysis Tool)。使用WCAT，你可以測試你的IIS服務器和網絡配置響應各種各樣的客戶請求，數據或HTML頁面的能力。這些測試結果能夠被用來作爲優化你的服務器和網絡配置的指導。WCAT是專門設計用來估計Windows 2000中的因特網服務(或Windows NT)和IIS 能響應的客戶工作量
(仿真)。爲了得到更多的信息，請參閱IIS Resource Kit(資源工具包)。那裏也有冗長的WCAT用戶指南在MSDN在線Web sorkshop站點裏面有一個下載鏈接。如果你認真對待你的Asp 性能的話，務必取得該工具。
力求最優化應用程序性能，你的web 應用程序會運行更加順暢。如果不是真正需要，就不要影響服務器的性能。
摘要：
上面介紹了有關ASP性能的資料，有很多因素影響Asp的性能，這裏只討論了其中的一部分。作爲最終的想法，不要認爲你能夠處理好所有的因素，你的ASP 性能還是有必要提高的。你發佈的每個應用程序必須個別進行考慮，所有以上的技巧並不是適合每個Asp程序。
