最大限度優(yōu)化你的Asp性能
當(dāng)前位置:點晴教程→知識管理交流
→『 技術(shù)文檔交流 』
ASP 能快速執(zhí)行你的動態(tài)網(wǎng)頁,但你還可以通過緊縮代碼和數(shù)據(jù)庫連接以使它們執(zhí)行更快。這是一篇關(guān)于怎樣精簡代碼和Asp 特征以獲得最快執(zhí)行速度的詳細(xì)文章。對于一個急燥的用戶來說,任何在按下用戶按鈕到結(jié)果出現(xiàn)在它們的屏幕之間的延遲可能意味著它們會轉(zhuǎn)到瀏覽其它的站點?假如你的是商業(yè)站點,這有可能意味著失去潛在的銷售。
我們沒有任何辦法控制用戶的帶寬,但我們的確能通過優(yōu)化Asp 站點來獲得最佳的性能。大部分潛在性能的提升是通過系統(tǒng)改變而不是緊縮代碼,一個不合適的想法是,一旦遇到系統(tǒng)效率問題,就向系統(tǒng)管理者提意見要其升級系統(tǒng)。 首先,哪個因素可能影響Asp的性能?很不幸,有很多因素?下面這些只是其中的一部分: 可用帶寬 服務(wù)器上的處理器和其它硬件的速度 在服務(wù)器上運行的其它程序(比如象那些OpenGL屏幕保護程序!) 數(shù)據(jù)庫連接模式,連接池,數(shù)據(jù)庫系統(tǒng)本身(比如Oracle優(yōu)于Sql Server,Sql server優(yōu)于Access) 所使用的語言 存儲過程優(yōu)于行式Sql語句 使用編譯組件而不是VB或JavaScript,好的Asp編程經(jīng)驗,比如錯誤處理等 一些以上的因素可能已經(jīng)被有IIS 知識經(jīng)驗的開發(fā)者普遍留意到了,但其它的可能對于他們來說是十分復(fù)雜的問題。在這篇文章里, 將試著解釋所有影響Asp性能的每個因素,讓我們看一看那些在我們刮胡子的幾毫秒內(nèi)就能做到的主要事情。 ASP腳本大小 你是腳本頁(還有其它頁面)是不是比必須的長度要長?這是一開始執(zhí)行就會降低Asp 性能的東西。ASP 腳本在用來獲取信息和格式化輸出的時候是十分有用的,但腳本也是逐行解釋執(zhí)行,所以你的腳本越長,執(zhí)行它的時間也就越長。 如果你的腳本很龐大,怎么做才能減少腳本的長度呢?這里有幾點建議: 你可以將它們轉(zhuǎn)換成服務(wù)器端組件,也就是說,做成VB動態(tài)鏈接庫DLL或者通過先進的Windows編程語言或適當(dāng)?shù)腃OM 接口語言將它轉(zhuǎn)換成未編譯組件?并且在服務(wù)器端注冊它們。有關(guān)的快速指南可以在 http://www.webdevelopersjournal.com/articles/activex_for_asp.html找到。對一個寫得好的ActiveX 組件進行編譯不但能大幅度提高性能,還可以保護你的軟件(腳本),尤其當(dāng)你將你的Asp站點發(fā)布在第三方主機上的時候。 因為腳本是逐行解釋執(zhí)行的,所以剔除多余的腳本或建立更高效率的腳本能夠改進性能。如果你在單個Asp 文件中有數(shù)百行的代碼,可能這樣做你能很好地劃分使用者,買賣和數(shù)據(jù)服務(wù)。事實上,如果你這樣做,可能會找出一些冗余的代碼:如果你需要輸出幾個表格,你可以編寫一個通用函數(shù)來輸出一個表格,只是多次調(diào)用它。 在講述Asp 腳本的大小問題的時候,不得不提及包含文件的大小。當(dāng)你使用一個包含文件的時候,整個包含文件被裝入,當(dāng)包含文件被包含的時候,相當(dāng)于在Asp 文件本身寫下那部分代碼。因此,如果你在一個冗長的包含文件里定義了很多通用的方法和定義,要明白到在你包含該文件的時候,不管你要不要用到里面的每個方法和定義,它都是被整個裝入的。ASP 緩存全部的展開代碼,這會降低查找效率在這種情況下,包含文件必須被分割成更小的,模塊化的文件。也要明白到包含文件被服務(wù)器視為單獨的頁面請求,使用太多的包含文件會影響下載時間。 <!-- #include file="Header.asp" --> 假如你的腳本冗長的話,請使用Response.IsClientConnected。這意味著在客戶端不再連接到服務(wù)器的時候,你的服務(wù)器CPU能避免循環(huán)等待。<% Interspersing ASP and HTML每個人都這樣做?當(dāng)我們輸出表格的時候,我們會在ASP 和HTML代碼間轉(zhuǎn)換,而這是一個不好的習(xí)慣。例如: <HTML> 另一個普遍的例子是使用IF語句的時候:<% 在這些情況下,腳本性能能通過將服務(wù)器端腳本寫到一起來,而用Response.write產(chǎn)生Html代碼來提高性能。比如:<% 在大的腳本和很多腳本的情況下,你將能看到性能的提高。注意這里盡量避免了使用<%標(biāo)記,這樣就能提高性能,ASP不需在執(zhí)行腳本的時候計算字符的Ascii碼。Session狀態(tài) 無庸置疑地,在Asp中能夠通過Session維持某個狀態(tài)的能力是十分強大的特色。然而,它會影響你的性能。明顯地,你的站點的可伸縮性性變成了另一個問題,如果限制Session的使用的話。然而,session會為每個用戶消耗服務(wù)器資源。 如果你不使用session 變量,或事實上你不必使用?使用隱藏表單域,在數(shù)據(jù)庫中保存數(shù)據(jù),查詢字符串是不是其中的竅門?所以你應(yīng)該禁止Session狀態(tài)。你可以使用下面的聲明禁止使用session: @EnableSessionState = False 這樣,ASP將不再檢查session信息。 如果你不得不依賴于session狀態(tài),應(yīng)該避免在session對象中存放大量的數(shù)據(jù)。IIS中的session在客戶端的HTTP cookie可用的時候就會保持,導(dǎo)致被session占用的內(nèi)存在session 終止或超時前一直被占用。這樣,如果很多用戶同時使用你的程序的時候,你的服務(wù)器資源可能會耗盡。 數(shù)據(jù)庫訪問 數(shù)據(jù)庫訪問是必須的麻煩?訪問數(shù)據(jù)庫將會激烈地減慢你的程序,但很顯然,如果沒有數(shù)據(jù)庫,很多站點將變得毫無價值可言。但通過存儲過程訪問數(shù)據(jù)庫來代替使用嵌入式Sql 語句,你可以提升潛在的性能。通過使用存儲過程和ActiveX Data Objects (ADO),它們亦同樣擁有良好的靈活性。盡可能從存儲過程來輸出數(shù)據(jù)。 確認(rèn)你的數(shù)據(jù)庫具有索引,因為這樣能直接提高你的程序的效率。同樣,盡量在你的數(shù)據(jù)庫服務(wù)器運行更新統(tǒng)計(Update Statistics) 以幫助追蹤你的數(shù)據(jù)分發(fā),這樣,你的數(shù)據(jù)庫就能夠基于這些信息來改造查詢執(zhí)行。注意一些數(shù)據(jù)庫比如MS Access,是不是真正能在企業(yè)級程序中接受?SQL Sever 7.0或者Oracle是一個更好的賭注。 讓SQL象它被設(shè)計的那樣工作,它能count(統(tǒng)計),連接(join),排序(sort)和group 數(shù)據(jù)。當(dāng)你能夠?qū)懗鲆粋€查詢語句來做這些東西的時候,就不要自己用其它語言來實現(xiàn)。 下面是一個統(tǒng)計所有列的最簡單的語法: SELECT count(*) FROM publishers WHERE state='NY' 如果你統(tǒng)計一個指定的列,你必須使用group by語句來分組該列,否則它不會工作:SELECT count(city),city FROM publishers GROUP BY city 分類返回的數(shù)據(jù):SELECT * FROM TableName WHERE FieldName>50 OR FieldName<100 ORDER BY FieldName2, Field Name3 使用Odbc還是文件DSN連接數(shù)據(jù)庫?使用快速的OLEDB Provider技術(shù)連接你的數(shù)據(jù)庫而不是使用DSN連接。不再需要懇求你的ISP(或數(shù)據(jù)庫管理員/網(wǎng)管)為你建立一個系統(tǒng)DSN,當(dāng)你移走Web文件的時候,亦不需要改變配置。OLEDB 介于ODBC層和應(yīng)用程序之間。在你的ASP 頁面中,ADO介于ODEDB之上的“應(yīng)用程序”。你的ADO調(diào)用首先被送到OLEDB,接著被送到ODBC層。然而,你可以直接連接到OLEDB 層,并且如果你這樣做的話,你就能看到服務(wù)器端性能的提高。然而,怎樣直接連接到OLEDB? 如果你使用SQLServer 7,使用下面的連接代碼連接數(shù)據(jù)庫: strConnString = "DSN='';DRIVER={SQL SERVER};" & _ 最重要的參數(shù)是DRIVER=部分。如果你要繞過ODBC而使用通過使用OLEDB 連接SQL Server(這是更快的連接),請使用下面的語法:strConnString ="Provider=SQLOLEDB.1;Password=mypassword;" & _ 有什么不對的地方嗎?現(xiàn)在你可能會覺得有點奇怪:我們在這個新的連接方法中的要點是什么呢?為什么不使用標(biāo)準(zhǔn)DSN-less/System DSN途徑?呵,根據(jù)Wrox 在他的著作《ADO 2.0 Programmer's Reference》中測試的結(jié)果表明,如果你使用OLEDB連接和DSN或者DSN-less連接方法比較,你會發(fā)現(xiàn)有下面的改進: 性能對比: SQL Access OLEDBDSNOLEDBDSN 連接時間:18?82?連接時間:62?99 查詢1,000條記錄時間:29005400查詢1,000條記錄時間: 100950 注釋:這個結(jié)果在Wrox的《ADO 2.0 Programmer's Reference》一書的第232和233頁可以查到。時間的單位是毫秒,查詢1,000記錄時間是通過服務(wù)器端游標(biāo)計算出來的(當(dāng)使用客戶端游標(biāo)的時候,OLEDB與DSN記錄集的性能之間的差別不大)。 ASP譯碼問題: 盡可能在客戶端確認(rèn)用戶輸入來減少HTTP來回請求的數(shù)量。如果瀏覽器有支持JavaScript或其它腳本的能力,使用它們的力量以釋放更多的服務(wù)器資源。 下面的VBScript運行于客戶端瀏覽器,在提交到你的服務(wù)器之前,用來驗證用戶信息: <SCRIPT LANGUAGE="VBScript"> 使用局部變量,避免使用全局變量。局部變量比全局變量更快地被Asp 腳本引擎存取,因為不需搜索整個名稱域。避免改變數(shù)組定義。在第一次初始化的時候就簡單分配足夠的大小效率更高。在這種情況下,你可能會浪費一些內(nèi)存,但你獲得了速度的優(yōu)勢。在服務(wù)器負(fù)載重的時候這個技術(shù)是顯然易見有效的。如果你需要引用不一定要用到的對象,那么最好使用<OBJECT>標(biāo)記而不是用 Server.CreateObject方法。 使用Server.CreateObject引起對象立即被建立,反之,<OBJECT>標(biāo)記則不會這樣立即建立對象如果使用<object>定義后不使用該對象,你不會浪費資源。 例如:下面的例子是一個使用<OBJECT>標(biāo)記建立一個application-scope廣告輪 Ad Rotator對象實 例: <OBJECT runat=server scope=Application id=MyAds progid="MSWC.AdRotator"> </OBJECT> 在存儲該Ad Rotator對象進Application后,你可以在任何程序的頁面中用下面的語法訪問該對象 <%=MyAds.GetAdvertisement("CustomerAds.txt") %> 打開'Option Explicit'開關(guān)。在VB和VBScript 中,你可以在沒有顯式聲明的情況下使用變量。但打開這個選項可以鑒別用定義變量,這樣可以很好地書寫變量,并能幫助提高性能。未定義的局部變量會變慢,因為在建立它之前,名稱空間必須被搜遍后才知道變量是否存在。擺脫它,使每個變量清楚地定義(先定義后使用)。這是一個好習(xí)慣,it may trap typos, 這樣更快。 除非你真正需要使用,否而不要使用Server.MapPath方法。如果你知道真實路徑就使用真實路徑。使用MapPath需要IIS找回現(xiàn)時服務(wù)器路徑,這意味著得向服務(wù)器發(fā)一個特殊的請求,也就意味著降低了性能。另一個方法是將路徑存放到局部變量中,在需要的時候使用,這樣就不需要服務(wù)器多次查找。 檢查你自己是怎么做的 你可以通過工具來測量你的系統(tǒng)性能,比如系統(tǒng)性能監(jiān)視器,NetMon和PerfMon。測試web性能可以用WCAT (Web Capacity Analysis Tool)。使用WCAT,你可以測試你的IIS服務(wù)器和網(wǎng)絡(luò)配置響應(yīng)各種各樣的客戶請求,數(shù)據(jù)或HTML頁面的能力。這些測試結(jié)果能夠被用來作為優(yōu)化你的服務(wù)器和網(wǎng)絡(luò)配置的指導(dǎo)。WCAT是專門設(shè)計用來估計Windows 2000中的因特網(wǎng)服務(wù)(或Windows NT)和IIS 能響應(yīng)的客戶工作量 (仿真)。為了得到更多的信息,請參閱IIS Resource Kit(資源工具包)。那里也有冗長的WCAT用戶指南在MSDN在線Web sorkshop站點里面有一個下載鏈接。如果你認(rèn)真對待你的Asp 性能的話,務(wù)必取得該工具。 力求最優(yōu)化應(yīng)用程序性能,你的web 應(yīng)用程序會運行更加順暢。如果不是真正需要,就不要影響服務(wù)器的性能。 摘要: 上面介紹了有關(guān)ASP性能的資料,有很多因素影響Asp的性能,這里只討論了其中的一部分。作為最終的想法,不要認(rèn)為你能夠處理好所有的因素,你的ASP 性能還是有必要提高的。你發(fā)布的每個應(yīng)用程序必須個別進行考慮,所有以上的技巧并不是適合每個Asp程序。 該文章在 2010/8/19 23:47:50 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |