微軟建議的ASP性能優(yōu)化28條守則
當(dāng)前位置:點(diǎn)晴教程→知識管理交流
→『 技術(shù)文檔交流 』
本文介紹了優(yōu)化 ASP 應(yīng)用程序和 Visual Basic® Scripting Edition (VBScript) 的技巧。本文討論了許多陷阱。本文列出的建議已經(jīng)在 http://www.microsoft.com 和其它站點(diǎn)中進(jìn)行了測試,效果十分顯著。本文假定您已經(jīng)對 ASP 開發(fā),包括 VBScript 和/或 JScript、ASP Application、ASP Session 和其它 ASP 固有對象(Request、Response 和 Server)有了基本了解。 通常,ASP 性能主要取決于 ASP 代碼本身以外的很多因素。我們不在一篇文章中羅列出所有的信息,在本文結(jié)尾處我們列出了與性能有關(guān)的資源。這些鏈接涵蓋了 ASP 和非 ASP 主題,包括 ActiveX® 數(shù)據(jù)對象 (ADO)、組件對象模型 (COM)、數(shù)據(jù)庫和 Internet Information Server (IIS) 配置。這些都是我們喜歡的一些鏈接 - 一定要去看看。 技巧 1:將經(jīng)常使用的數(shù)據(jù)緩存在 Web 服務(wù)器上 典型的 ASP 頁從后端數(shù)據(jù)存儲中檢索數(shù)據(jù),然后將結(jié)果轉(zhuǎn)換成超文本標(biāo)記語言 (HTML)。無論數(shù)據(jù)庫的速度如何,從內(nèi)存中檢索數(shù)據(jù)總要比從后端數(shù)據(jù)存儲中檢索數(shù)據(jù)快得多。從本地硬盤讀取數(shù)據(jù)通常也比從數(shù)據(jù)庫中檢索數(shù)據(jù)更快。因此,通??梢詫?shù)據(jù)緩存在 Web 服務(wù)器上(存儲在內(nèi)存或磁盤中),來提高性能。 緩存是傳統(tǒng)的以空間換取時(shí)間的做法。如果您緩存的內(nèi)容正確,那么您可以看到性能會有顯著的提高。為使緩存有效,必須保存那些經(jīng)常重復(fù)使用的數(shù)據(jù),且要重新計(jì)算這些數(shù)據(jù)需要(適度)大的開銷。如果緩存的都是些陳舊的數(shù)據(jù),就會造成內(nèi)存浪費(fèi)。 不經(jīng)常發(fā)生改變的數(shù)據(jù)是很好的緩存候選數(shù)據(jù),因?yàn)槟槐負(fù)?dān)心隨著時(shí)間的遷移該數(shù)據(jù)與數(shù)據(jù)庫同步的問題。組合框列表、引用表、DHTML 碎片、擴(kuò)展標(biāo)記語言 (XML) 字符串、菜單項(xiàng)和站點(diǎn)配置變量(包括數(shù)據(jù)源名稱 (DSN)、Internet 協(xié)議 (IP) 地址和 Web 路徑)都是很好的緩存候選內(nèi)容。注意您可以緩存數(shù)據(jù)的“表示”,而不緩存數(shù)據(jù)本身。如果 ASP 頁很少更改,且緩存的開銷也很大(例如,整個(gè)產(chǎn)品目錄),則應(yīng)考慮事先產(chǎn)生 HTML,而不是在響應(yīng)每個(gè)請求時(shí)重新顯示。 應(yīng)將數(shù)據(jù)緩存在哪里,有哪些緩存策略?通常,數(shù)據(jù)緩存在 Web 服務(wù)器的內(nèi)存或磁盤中。下兩個(gè)技巧講述了這兩個(gè)方法。 技巧 2: 將經(jīng)常使用的數(shù)據(jù)緩存在 Application 或 Session 對象中 ASP Application 和 Session 對象為將數(shù)據(jù)緩存在內(nèi)存中提供了方便的容器。您可以將數(shù)據(jù)指派到 Application 和 Session 對象中,這些數(shù)據(jù)在 HTTP 調(diào)用之間保留在內(nèi)存中。Session 數(shù)據(jù)是按每個(gè)用戶分別存儲的,而 Application 數(shù)據(jù)則在所有用戶之間共享。 什么時(shí)候?qū)?shù)據(jù)裝載到 Application 或 Session 中呢?通常,數(shù)據(jù)是在啟動 Application 或 Session 時(shí)裝載。要在 Application 或 Session 啟動過程中裝載數(shù)據(jù),應(yīng)將適當(dāng)?shù)拇a分別添加到 Application_OnStart() 或 Session_OnStart() 中。這些函數(shù)應(yīng)在 Global.asa 中,如果沒有,則可以添加這些函數(shù)。還可以在第一次需要時(shí)裝載該數(shù)據(jù)。為此,在 ASP 頁中添加一些代碼(或編寫一個(gè)可重復(fù)使用的腳本函數(shù)),以檢查數(shù)據(jù)是否存在,如果不存在,就裝載數(shù)據(jù)。這是一個(gè)傳統(tǒng)的性能技術(shù),稱為“惰性計(jì)算” - 在您知道需要某一個(gè)值以前不計(jì)算該值。例如: <% 可以為所需要的每個(gè)數(shù)據(jù)塊編寫類似的函數(shù)。 應(yīng)以什么格式存儲數(shù)據(jù)?可以存儲任何變體類型,因?yàn)樗心_本變量都是變體型。例如,您可以存儲字符串、整數(shù)或數(shù)組。通常,您將以這些變量類型之一存儲 ADO 記錄集的內(nèi)容。要從 ADO 記錄集獲取數(shù)據(jù),您可以手工將數(shù)據(jù)復(fù)制到 VBScript 變量,一次一個(gè)字段。使用一個(gè) ADO 記錄集持久函數(shù) GetRows()、GetString() 或 Save()(ADO 2.5),可加快速度且更容易一些。其詳細(xì)情況已超出本文所討論的范圍,但下面給出了一個(gè)函數(shù)舉例,說明使用 GetRows() 返回記錄集數(shù)據(jù)的一個(gè)數(shù)組: ' Get Recordset, return as an Array
' Get Recordset, return as HTML Option list 在適當(dāng)?shù)臈l件下,可以將 ADO 記錄集本身緩存在 Application 或 Session 作用域中。有兩個(gè)警告: 必須將 ADO 標(biāo)記為自由線程 當(dāng)您將數(shù)據(jù)存儲在 Application 或 Session 作用域時(shí),數(shù)據(jù)將保留在那里,直到您以編程方式改變它、Session 過期或 Web 應(yīng)用程序重新啟動為止。如果數(shù)據(jù)需要更新怎么辦?要手工強(qiáng)制對 Application 數(shù)據(jù)進(jìn)行更新,您可以訪問只有管理員才可訪問的 ASP 頁來更新數(shù)據(jù)。或者,您可以通過函數(shù)定期自動刷新數(shù)據(jù)。下面例子存儲帶有緩存數(shù)據(jù)的時(shí)間戳,并隔一段時(shí)間后刷新數(shù)據(jù)。 <% 請參見 World's Fastest ListBox with Application Data,上面還有一個(gè)例子。 要知道在 Session 或 Application 對象中緩存大的數(shù)組不是一個(gè)好的做法。在訪問數(shù)組的任何元素之前,腳本語言的語法要求必須臨時(shí)復(fù)制整個(gè)數(shù)組。例如,如果將由字符串組成的有 100,000 個(gè)元素的數(shù)組(該數(shù)組將美國郵政編碼映射到當(dāng)?shù)氐臍庀笳荆┚彺嬖?Application 對象中,ASP 必須先將所有的 100,000 個(gè)氣象站復(fù)制到臨時(shí)數(shù)組中,然后才能提取一個(gè)字符串。在這種情況下,用自定義方法建立一個(gè)自定義組件來存儲氣象站 - 或使用一個(gè)詞典組件會更好。 再警告大家一下,不要將嬰兒與洗澡水一起倒掉:數(shù)組能快速查尋和存儲在內(nèi)存中是鄰近的關(guān)鍵數(shù)據(jù)對。索引一個(gè)詞典比索引一個(gè)數(shù)組要慢得多。應(yīng)針對您的實(shí)際情況,選擇提供最佳性能的數(shù)據(jù)結(jié)構(gòu)。 #p# 技巧 3:將數(shù)據(jù)和 HTML 緩存在 Web 服務(wù)器的磁盤上 有時(shí),數(shù)據(jù)可能太多,無法都緩存在內(nèi)存中?!疤唷敝皇且粋€(gè)說法,這要看您想消耗多少內(nèi)存,以及需緩存的項(xiàng)目數(shù)和檢索這些項(xiàng)目的頻率。在任何情況下,如果數(shù)據(jù)太多而無法都緩存在內(nèi)存中,則考慮將數(shù)據(jù)以文本或 XML 文件緩存在 Web 服務(wù)器的硬盤上??梢酝瑫r(shí)將數(shù)據(jù)緩存在磁盤和內(nèi)存中,為您的站點(diǎn)建立最適宜的緩存策略。 注意當(dāng)測量單個(gè) ASP 頁的性能時(shí),檢索磁盤上的數(shù)據(jù)可能不一定要比從數(shù)據(jù)庫檢索數(shù)據(jù)更快。但緩存會降低數(shù)據(jù)庫和網(wǎng)絡(luò)上的負(fù)載。在高負(fù)載的情況下,這樣做可大大改善總體吞吐量。當(dāng)緩存開銷很大的查詢結(jié)果(如多表聯(lián)接或復(fù)合存儲過程)或大的結(jié)果集時(shí),這是非常有效的。與往常一樣,要測試一下幾種方案的優(yōu)劣。 ASP 和 COM 提供一些建立基于磁盤的緩存方案的工具。ADO 記錄集 Save() 和 Open() 函數(shù)保存和裝載磁盤中的記錄集??梢允褂眠@些方法重新編寫上面 Application 數(shù)據(jù)緩存技巧中的代碼示例,用文件的 Save() 代替寫到 Application 對象中的代碼。 有一些其它組件可以用于文件: Scripting.FileSystemObject 可使您創(chuàng)建、讀和寫文件。 技巧 4:避免將非敏捷的組件緩存在 Application 或 Session 對象中 盡管將數(shù)據(jù)緩存在 Application 或 Session 對象中是一個(gè)好的做法,但緩存 COM 對象卻有嚴(yán)重的陷阱。通常,人們傾向于將經(jīng)常使用的 COM 對象緩存到 Application 或 Session 對象中。很遺憾,許多 COM 對象(包括所有以 Visual Basic 6.0 或更低版本編寫的對象)當(dāng)存儲在 Application 或 Session 對象時(shí),會引起嚴(yán)重的瓶頸。 具體來講,當(dāng)任何不敏捷的組件緩存在 Session 或 Application 對象時(shí),將引起性能瓶頸。敏捷的組件是被標(biāo)記為 ThreadingModel=Both 的組件,它聚集 Free-threaded marshaler (FTM);或被標(biāo)記為 ThreadingModel=Neutral 的組件。(Neutral 模型是 Windows® 2000 和 COM+ 的新增模型。) 下列組件不是敏捷的: 自由線程的組件(除非它們聚集 FTM)。 在 IIS 4.0 中,被標(biāo)記為 ThreadingModel=Both 的組件被認(rèn)為是敏捷的。在 IIS 5.0 中,只有這一點(diǎn)還不夠。組件必須不僅被標(biāo)記 Both,還必須聚集 FTM。有關(guān)敏捷性的文章講述了如何使以 Active Template Library 編寫的 C++ 組件聚集 FTM。要注意如果組件緩存界面指針,那么那些指針本身必須是敏捷的,或必須存儲在 COM 共用界面表 (GIT) 中。如果您不能重新編譯 Both 線程組件以聚集 FTM,那么您可以將組件標(biāo)記為 ThreadingModel=Neutral?;蛘?,如果您不想讓 IIS 執(zhí)行敏捷性檢查(因此,您可以允許非敏捷的組件存儲在 Application 或 Session 作用域中),您可以在配置數(shù)據(jù)庫中將 AspTrackThreadingModel 設(shè)置為 True。不建議更改 AspTrackThreadingModel。 如果您想將以 Server.CreateObject 創(chuàng)建的非敏捷的組件存儲在 Application 對象中,IIS 5.0 將出現(xiàn)一個(gè)錯誤。您可以在 Global.asa 中使用 <object runat=server scope=application ...> 避免這一錯誤,但不建議這樣做,因?yàn)檫@會導(dǎo)致匯集和串行化,關(guān)于這一點(diǎn)將在下面講述。 如果您緩存非敏捷的組件會出現(xiàn)什么毛病?緩存在 Session 對象中的非敏捷的組件將 Session 鎖定于 ASP 工作者線程。ASP 維護(hù)一個(gè)工作者線程池來處理請求。通常情況下,一個(gè)新請求總是由第一個(gè)可用的工作者線程來處理。如果 Session 被鎖定于一個(gè)線程,那么請求必須等到其相關(guān)的線程可用為止。這里有一個(gè)類比,也許會有所幫助:您去一家超級市場,挑選了一些商品,并在 #_3 收款臺付款。其后,每當(dāng)您在那家超級市場為商品付款時(shí),您總是必須在 #_3 收款臺付款,即使其它收款臺前排隊(duì)的人較少或者沒有人排隊(duì),也是如此。 將非敏捷的組件存儲在 Application 作用域?qū)π阅艿挠绊懮踔粮鼔?。ASP 必須創(chuàng)建一個(gè)特殊的線程運(yùn)行存儲在 Application 作用域中的非敏捷組件。這會有兩個(gè)結(jié)果:所有調(diào)用都必須匯集到此線程,且所有調(diào)用都排成長隊(duì)。“匯集”的意思是參數(shù)必須存儲在內(nèi)存的共享區(qū)域;執(zhí)行一個(gè)開銷很大的到特殊線程的上下文切換;執(zhí)行組件的方法;將結(jié)果匯集到共享區(qū)域;執(zhí)行另一個(gè)開銷很大的上下文切換,將控制返回到原始的線程。“串行化”意思是指每次只運(yùn)行一個(gè)方法。兩個(gè)不同的 ASP 工作者線程不能同時(shí)在共享組件上執(zhí)行多個(gè)方法。這樣就杜絕了并發(fā)性,特別是在多處理器計(jì)算機(jī)上。更糟的是,所有非敏捷的 Application 作用域的組件共享一個(gè)線程(主機(jī) STA),因此串行化的影響甚至更顯著。 如之奈何?下面是一些一般的規(guī)則。如果您使用 Visual Basic (6.0) 或更早版本編寫對象,那么不要將它們緩存在 Application 或 Session 對象中。如果您不知道對象的線程模型,不要緩存它。不要緩存非敏捷的對象,而應(yīng)在每個(gè)頁面創(chuàng)建和釋放它們。對象直接在 ASP 工作者線程上運(yùn)行,因此沒有匯集或串行化。如果 COM 對象在 IIS 服務(wù)器上運(yùn)行,且如果它們不花長時(shí)間初始化和刪除,性能尚可。注意單線程對象不應(yīng)該這樣使用。小心 - VB 可創(chuàng)建單線程對象!如果您必須這樣使用單線程對象(如 Microsoft Excel 電子表格),別指望會有很高的吞吐量。 當(dāng) ADO 被標(biāo)記為自由線程,ADO 記錄集可以安全地緩存。要將 ADO 標(biāo)記為自由線程,使用 Makfre15.bat 文件,該文件通常位于目錄 \\Program Files\Common\System\ADO 中。 警告 如果您使用 Microsoft Access 作為數(shù)據(jù)庫,不應(yīng)將 ADO 標(biāo)記為自由線程的。ADO 記錄集也必須切斷連接。一般來說,如果您不能控制站點(diǎn)中的 ADO 配置(例如,您是一個(gè)獨(dú)立的軟件廠商 [ISV],向管理他們自己的配置客戶銷售 Web 應(yīng)用程序),最好不要緩存記錄集。 詞典組件也是敏捷的對象。LookupTable 從數(shù)據(jù)文件中裝載其數(shù)據(jù),可用于組合框數(shù)據(jù)和配置信息。Duwamish Books 中的 PageCache 對象可提供詞典語法,Caprock Dictionary 也可提供。這些對象或其派生對象可以構(gòu)成有效緩存策略的基礎(chǔ)。注意 Scripting.Dictionary 對象不是敏捷的,不應(yīng)該存儲在 Application 或 Session 作用域中。 技巧 5:不要將數(shù)據(jù)庫連接緩存在 Application 或 Session 對象中 緩存 ADO 連接通常是很糟糕的策略。如果一個(gè) Connection 對象存儲在 Application 對象中,并在所有的頁面中使用,那么所有頁面將爭搶這一連接。如果 Connection 對象存儲在 ASP Session 對象中,那么將為每個(gè)用戶創(chuàng)建數(shù)據(jù)庫連接。這就會使連接池的優(yōu)勢蕩然無存,并給 Web 服務(wù)器和數(shù)據(jù)庫帶來不必要的壓力。 可以不緩存數(shù)據(jù)庫連接,而是在使用 ADO 的每個(gè) ASP 頁面中創(chuàng)建和刪除 ADO 對象。這是很有效的,因?yàn)?IIS 內(nèi)嵌了數(shù)據(jù)庫連接池。更準(zhǔn)確地說,IIS 自動啟用 OLEDB 和 ODBC 連接池。這就能確保在每個(gè)頁面上創(chuàng)建和刪除連接將是有效的。 因?yàn)檫B接的記錄集存儲一個(gè)到數(shù)據(jù)庫連接的引用,所以您不應(yīng)將連接的記錄集緩存在 Application 或 Session 對象中。但是,您可以安全地緩存斷開連接的記錄集,它們不保存到其數(shù)據(jù)連接的引用。要斷開記錄集連接,執(zhí)行下面的兩個(gè)步驟: Set rs = Server.CreateObject(?ADODB.RecordSet?) 有關(guān)連接池的更詳細(xì)信息,可以在 ADO 和 SQL Server 參考資料中找到。 技巧 6:合理地使用 Session 對象 既然我們已經(jīng)討論了緩存在 Application 和 Session 中的優(yōu)點(diǎn),現(xiàn)在開始討論避免使用 Session 對象的問題。正如下面所討論的,當(dāng)與忙的站點(diǎn)一起使用時(shí),Session 有幾個(gè)缺點(diǎn)?!懊Α钡囊馑家话闶侵敢幻腌娨髱装夙撁婊虺汕先f同時(shí)用戶的站點(diǎn)。這個(gè)技巧對于必須水平擴(kuò)展的站點(diǎn) - 即,那些利用多臺服務(wù)器以處理負(fù)載或?qū)崿F(xiàn)容錯的站點(diǎn) - 甚至更重要。對于較小的站點(diǎn),諸如 Intranet 站點(diǎn),要想實(shí)現(xiàn) Session 帶來的方,必然增大系統(tǒng)開銷。 簡言之,ASP 自動為每個(gè)訪問 Web 服務(wù)器的用戶創(chuàng)建一個(gè) Session。每個(gè) Session 大約需要 10 KB 的內(nèi)存開銷(最主要的是數(shù)據(jù)存儲在 Session 中),這就使所有的請求都減慢。在配置的超時(shí)時(shí)段(通常是 20 分鐘)結(jié)束以前,Session 一直保留有效。 Session 的最大的問題不是性能,而是可擴(kuò)展性。Session 不能跨越幾臺 Web 服務(wù)器,一旦在一臺服務(wù)器上創(chuàng)建 Session,其數(shù)據(jù)就留在那兒。這就意味著如果您在一個(gè) Web 服務(wù)器群使用 Session,您必須設(shè)計(jì)一個(gè)策略,將每個(gè)用戶請求始終發(fā)到用戶 Session 所在的那臺服務(wù)器上。這被稱為將用戶“粘”在 Web 服務(wù)器上。術(shù)語“粘性會話”就是從這里派生而來的。如果 Web 服務(wù)器崩潰,被“粘住的”用戶將丟失他們的會話狀態(tài),因?yàn)闀挷皇钦车酱疟P上。 實(shí)現(xiàn)粘性會話的策略包括硬件和軟件解決方案。諸如 Windows 2000 Advanced Server 中的網(wǎng)絡(luò)負(fù)載平衡和 Cisco 的 Local Director 之類的解決方案都可以實(shí)現(xiàn)粘性會話,代價(jià)是要損失一定程度的可擴(kuò)展性。這些解決方案是不完善的。不建議此時(shí)部署您自己的軟件解決方案(我們過去常常使用 ISAPI 篩選器和 URL 轉(zhuǎn)換等等)。 Application 對象也不跨越多臺服務(wù)器,如果您必須跨越 Web 服務(wù)器群共享和更新 Application 數(shù)據(jù),您必須使用后端數(shù)據(jù)庫。但是,只讀 Application 數(shù)據(jù)在 Web 服務(wù)器群中仍是有用的。 如果只是因?yàn)橐黾舆\(yùn)行時(shí)間(處理故障轉(zhuǎn)移和服務(wù)器維護(hù)),大多數(shù)關(guān)鍵任務(wù)站點(diǎn)至少需部署兩臺 Web 服務(wù)器。因此,在設(shè)計(jì)關(guān)鍵任務(wù)應(yīng)用程序時(shí),必須實(shí)現(xiàn)“粘性會話”,或干脆避免使用 Session,以及任何其它將用戶狀態(tài)存儲在單個(gè) Web 服務(wù)器上的狀態(tài)管理技術(shù)。 如果您不使用 Session,一定要將它們關(guān)閉。您可以通過 Internet Services Manager,為應(yīng)用程序執(zhí)行此操作(參見 ISM 文檔)。如果您決定使用 Session,您可以采用一些方法減輕它們對性能的影響。 您可以將不需要 Session 的內(nèi)容(如幫助屏幕,訪問者區(qū)域等等)移到另一個(gè)關(guān)閉了 Session 的 ASP 應(yīng)用程序中。您可以逐頁提示 ASP,您不再需要該頁面上的 Session 對象,使用以下放在 ASP 頁面最上面的指令: <% @EnableSessionState=False %> 使用這一指令有一個(gè)很好的理由是,這些 Session 在框架集方面存在一個(gè)有意思的問題。ASP 保證任何時(shí)候 Session 只有一個(gè)請求執(zhí)行。這樣就確保如果瀏覽器為一個(gè)用戶請求多個(gè)頁面,一次只有一個(gè) ASP 請求接觸 Session,這樣就避免了當(dāng)訪問 Session 對象時(shí)發(fā)生的多線程問題。很遺憾,一個(gè)框架集中的所有頁面將以串行方式顯示,一個(gè)接一個(gè),而不是同時(shí)顯示。用戶可能必須等候很長時(shí)間,才能看到所有的框架。該故事的寓意:如果某些框架集頁面不依靠 Session,一定要使用 @EnableSessionState=False 指令告訴 ASP。 有許多管理 Session 狀態(tài)的方法,可替代 Session 對象的使用。對于少量的狀態(tài)(少于 4 KB),我們通常建議使用 Cookies、QueryString 變量和隱式變量。對于更大數(shù)據(jù)量,如購物小車,后端數(shù)據(jù)庫是最適合的選擇。有關(guān) Web 服務(wù)器群中狀態(tài)管理技術(shù)的文章很多。有關(guān)詳細(xì)信息,請參見 Session 狀態(tài)參考資料。 技巧 7: 將代碼封裝在 COM 對象中 如果您有許多 VBScript 或 JScript,您可以經(jīng)常將代碼移到編譯的 COM 對象中,從而可改善性能。編譯的代碼通常比解釋的代碼運(yùn)行得更快。編譯的 COM 對象可以通過“早綁定”訪問其它 COM 對象,與腳本使用的“晚綁定”相比,“早綁定”是調(diào)用 COM 對象的更有效方法。 將代碼封裝在 COM 對象中還有一些優(yōu)點(diǎn)(除性能之外): COM 對象有利于將表示邏輯與業(yè)務(wù)邏輯分開。 有關(guān)在 ASP 中使用 COM 的優(yōu)點(diǎn)和缺點(diǎn)的詳細(xì)討論,參見 ASP Component Guidelines and Programming Distributed Applications with and Microsoft Visual Basic 6.0。如果您部署 COM 組件,以負(fù)荷對它們進(jìn)行測試特別重要。事實(shí)上,理所當(dāng)然應(yīng)對所有的 ASP 應(yīng)用程序進(jìn)行負(fù)荷測試。 #p# 技巧 8:遲一點(diǎn)獲得資源,早一點(diǎn)釋放資源 這里是一個(gè)小技巧供您參考。一般來說,最好遲一點(diǎn)獲得資源,早一點(diǎn)釋放資源。這適用于 COM 對象以及文件句柄和其它資源。 這種優(yōu)化方法主要用于 ADO 連接和記錄集。當(dāng)您使用完記錄集,比方說在顯示一個(gè)表及其數(shù)據(jù)之后,應(yīng)立即釋放它,而不是等到頁面結(jié)束時(shí)再釋放。將 VBScript 變量設(shè)置為 Nothing 是最好的做法。不要讓記錄集超出作用域之外。而且,要釋放任何相關(guān)的 Command 或 Connection 對象(在將記錄集或連接設(shè)置為 = Nothing 之前,不要忘記調(diào)用 Close())。這會縮短數(shù)據(jù)庫必須為您準(zhǔn)備資源的時(shí)間,并盡快釋放數(shù)據(jù)庫到連接池的連接。 技巧 9:進(jìn)程外執(zhí)行過程以性能換取可靠性 ASP 和 MTS/COM+ 兩者都有配置選項(xiàng),可使您兼顧可靠性和性能。當(dāng)建立和部署應(yīng)用程序時(shí),應(yīng)知道如何兼顧兩者的性能。 ASP 選項(xiàng) 低級隔離。這在 IIS 的所有版本中都得到支持,且是最快的。它在 Inetinfo.exe 中運(yùn)行 ASP,Inetinfo.exe 是主要 IIS 進(jìn)程。如果 ASP 應(yīng)用程序崩潰,IIS 也會崩潰。(要在 IIS 4.0 下重新啟動 IIS,Web 站點(diǎn)管理員應(yīng)使用諸如 InetMon 之類的工具監(jiān)視站點(diǎn),如果服務(wù)器發(fā)生故障,應(yīng)啟用批處理文件以重新啟動服務(wù)器。IIS 5.0 引入了可靠的重新啟動,該方法可使發(fā)生故障的服務(wù)器自動重新啟動。) 注意 當(dāng)您運(yùn)行 ASP 進(jìn)程外應(yīng)用程序時(shí)(中級或高級隔離),它們在 NT4 中的 MTS 和在 Windows 2000 中的 COM+ 中運(yùn)行。即,在 NT4 中它們在 Mtx.exe 中運(yùn)行;而在 Windows 2000 中,它們在 DllHost.exe 中運(yùn)行。您可以在任務(wù)管理器中看到這些進(jìn)程在運(yùn)行。您還可以看到 IIS 如何為進(jìn)程外 ASP 應(yīng)用程序配置 MTS 程序包或 COM+ 應(yīng)用程序。 COM 選項(xiàng) 您可以看到未配置的組件比庫應(yīng)用程序略有一些優(yōu)勢。庫應(yīng)用程序比服務(wù)器應(yīng)用程序的性能優(yōu)點(diǎn)更大。這是因?yàn)閹鞈?yīng)用程序與 ASP 在同一進(jìn)程內(nèi)運(yùn)行,而服務(wù)器應(yīng)用程序在它們的自有進(jìn)程內(nèi)運(yùn)行。進(jìn)程間的調(diào)用比進(jìn)程內(nèi)調(diào)用開銷更大。而且,當(dāng)在進(jìn)程之間傳遞諸如記錄集之類的數(shù)據(jù)時(shí),必須在兩個(gè)進(jìn)程之間復(fù)制所有的數(shù)據(jù)。 陷阱!當(dāng)使用 COM 服務(wù)器應(yīng)用程序時(shí),如果您在 ASP 和 COM 之間傳遞對象,要確保對象執(zhí)行“按值匯集”或 MBV。執(zhí)行 MBV 的對象將它們自己從一個(gè)進(jìn)程復(fù)制到另一個(gè)進(jìn)程。這比下面一種方法好,采用這種方法時(shí),對象仍在創(chuàng)建者的進(jìn)程中,另外一個(gè)進(jìn)程反復(fù)地調(diào)用創(chuàng)建進(jìn)程以使用該對象。切斷連接的 ADO 記錄集將“按值匯集”,連接的記錄集則不然。Scripting.Dictionary 不執(zhí)行 MBV,且不在進(jìn)程之間傳遞。最后,VB 程序員請注意:MBV 不通過傳遞參數(shù) ByVal 獲得。MBV 由原始的組件作者執(zhí)行。 怎么辦? 在 IIS 4.0 中,使用 ASP 低隔離級別,使用 MTS 服務(wù)器程序包。 技巧 10:使用顯式選項(xiàng) 在 .asp 文件中應(yīng)使用 Option Explicit。此指令放在 .asp 文件的最上面,它強(qiáng)制開發(fā)人員聲明要使用到的所有變量。許多程序員認(rèn)為這種方法對于調(diào)試應(yīng)用程序很有幫助,因?yàn)檫@種方法避免了鍵錯變量名和誤建新變量的可能性(例如,將 MyXMLString=) 錯寫成 MyXLMString=...。 更重要的一點(diǎn)也許是,聲明的變量比未聲明的變量速度更快。由此,腳本在運(yùn)行時(shí)每次用到未聲明的變量時(shí),按名稱引用它。另一方面,聲明的變量是有順序的,要么以編譯時(shí)間,要么以運(yùn)行時(shí)間。以后,聲明的變量都按此順序引用。因?yàn)?Option Explicit 強(qiáng)制變量聲明,它能確保聲明所有變量,因此訪問的速度也很快。 技巧 11:在子例程和函數(shù)中使用局部變量 局部變量是那些在子例程和函數(shù)內(nèi)聲明的變量。在函數(shù)或子例程內(nèi),局部變量訪問比全局變量訪問更快。局部變量的使用也會使代碼更清晰,因此應(yīng)盡量使用局部變量。 技巧 12:將經(jīng)常使用的數(shù)據(jù)復(fù)制到腳本變量中 當(dāng)訪問 ASP 中的 COM 對象時(shí),應(yīng)將經(jīng)常使用的對象數(shù)據(jù)復(fù)制到腳本變量中。這樣做可減少 COM 方法調(diào)用,因?yàn)?COM 方法調(diào)用與訪問腳本變量相比,開銷相對較大。當(dāng)訪問 Collection 和 Dictionary 對象時(shí),這種技術(shù)也會減少開銷很大的查找。 一般來說,如果您打算不止一次訪問對象數(shù)據(jù),那么就應(yīng)將數(shù)據(jù)放到腳本變量中。這種優(yōu)化的主要目標(biāo)是 Request 變量(Form 和 QueryString 變量)。例如,您的站點(diǎn)可傳遞一個(gè)名為 UserID 的 QueryString 變量。假設(shè)此 UserID 在特定頁面上被引用 12 次??梢詿o須調(diào)用 Request(?UserID?) 12 次,而是在 ASP 頁面最上面將 UserID 指派到一個(gè)變量。然后在該頁面自始至終使用該變量。這樣就省去了 11 次 COM 方法調(diào)用。 實(shí)際上,訪問 COM 屬性或方法的開銷并沒有那么大。下面舉一個(gè)例子,說明某相當(dāng)常見的代碼(從語法上講): Foo.bar.blah.baz = Foo.bar.blah.qaz(1) 當(dāng)此代碼運(yùn)行時(shí),下面是發(fā)生的情況: 變量 Foo 被解析為全局對象。 Set myobj = Foo.bar.blah ' do the resolution of blah ONCE 如果您使用 VBScript 5.0 或更高版本,您可以使用 With 語句寫此代碼: With Foo.bar.blah 注意此技巧也適用于 VB 程序設(shè)計(jì)。 技巧 13:避免重新確定數(shù)組的維數(shù) 應(yīng)盡量避免 Redim 數(shù)組。就性能而言,如果計(jì)算機(jī)的物理內(nèi)存大小有限,最好將數(shù)組的初始維數(shù)設(shè)置為其最不利的情況 - 或?qū)⒕S數(shù)設(shè)置為其最佳的情況,然后再按需要重新確定維數(shù)。這并非意味著,如果知道您不需要內(nèi)存時(shí),就隨便分配幾兆字節(jié)的內(nèi)存。 下面的代碼給您顯示使用 Dim 和 Redim 不當(dāng)?shù)那樾巍?/P> <% 最好一開始就將數(shù)組的初始大小 Dim 正確(在本例中,是 5)比 Redim 數(shù)組使其更大好得多。您可能浪費(fèi)一些內(nèi)存(如果您沒有使用所有的元素),但獲得的好處是速度變得更快。 #p# 技巧 14:使用響應(yīng)緩沖 您可以通過啟用“響應(yīng)緩沖”,將要輸出的一整頁緩沖起來。這樣就將寫到瀏覽器的量減到最少,從而改善總體性能。每個(gè)寫操作都會產(chǎn)生很大的系統(tǒng)開銷(在 IIS 中以及在通過網(wǎng)絡(luò)發(fā)送的數(shù)據(jù)量方面),因此寫操作越少越好。由于其啟動慢且使用 Nagling 算法(用來減輕網(wǎng)絡(luò)塞車情況),TCP/IP 在發(fā)送一些大的數(shù)據(jù)塊時(shí)比必須發(fā)送許多小的數(shù)據(jù)塊時(shí)的效率高得多。 有兩個(gè)方法啟用響應(yīng)緩沖。第一種,您可以使用 Internet Services Manager 為整個(gè)應(yīng)用程序啟用響應(yīng)緩沖。我們建議采用這種方法,在 IIS 4.0 和 IIS 5.0 中默認(rèn)為新的 ASP 應(yīng)用程序啟用響應(yīng)緩沖。第二種,可以在每個(gè) ASP 頁面的接近頂端的地方加入下面的代碼行,從而啟用響應(yīng)緩沖: <% Response.Buffer = True %> 此代碼行必須在任何響應(yīng)數(shù)據(jù)被寫到瀏覽器之前執(zhí)行(即,在任何 HTML 出現(xiàn)在 ASP 腳本之前以及在使用 Response.Cookies 集合設(shè)置任何 Cookies 之前)。一般來說,最好為整個(gè)應(yīng)用程序啟用響應(yīng)緩沖。這樣,您就不必在每個(gè)頁面最上面寫入上述的代碼行。 Response.Flush (注意在上面的 1,000 行表的舉例中,許多瀏覽器在它們看到關(guān)閉 </table> 標(biāo)記之前不會開始顯示表。檢查您的目標(biāo)瀏覽器是否支持。為避免這種情況,將表分成多個(gè)具有較少行的表,并在每個(gè)表之后調(diào)用 Response.Flush。較新版本的 Internet Explorer 在表完全下載之前就開始顯示表,如果您指定表列寬,顯示速度就會特別快,這樣做可避免強(qiáng)制 Internet Explorer 通過測量每個(gè)單元格的內(nèi)容寬度來計(jì)算列寬。) 另一個(gè)關(guān)于響應(yīng)緩沖的常見的抱怨是,當(dāng)產(chǎn)生非常大的頁面時(shí),將占用許多服務(wù)器內(nèi)存。撇開產(chǎn)生大頁面的方法不談,這種問題也可通過巧妙使用 Response.Flush 來加以解決。 技巧 15:批處理內(nèi)嵌腳本和 Response.Write 語句 VBScript 語法 <% = expression %> 將“expression”的值寫到 ASP 輸出流中。如果響應(yīng)緩沖未啟用,那么執(zhí)行其中的每一條語句,都會以許多小的數(shù)據(jù)包通過網(wǎng)絡(luò)將數(shù)據(jù)寫到瀏覽器中。這樣速度很慢。而且穿插執(zhí)行少量的腳本和 HTML,將引起腳本引擎和 HTML 之間的切換,從而降低性能。因此,使用下面的技巧:使用 Response.Write 調(diào)用代替捆綁緊密的內(nèi)嵌表達(dá)式。例如,在下面的示例中,在每一行的每一字段對響應(yīng)流有一次寫操作,每一行在 VBScript 和 HTML 之間有許多切換: <table> 下面的代碼更有效,每一行對響應(yīng)流有一次寫操作。所有的代碼都包含在一個(gè) VBScript 塊內(nèi): <table> 當(dāng)禁用響應(yīng)緩沖時(shí),這一技巧的效果特別大。最好啟用響應(yīng)緩沖,然后看批處理 Response.Write 是否有助于提高性能。 ?。ㄔ谶@一特定舉例中,建立表主體的嵌套循環(huán) (While Not rs.EOF...) 可以用仔細(xì)構(gòu)建的 GetString 調(diào)用來替代。) 技巧 16:如果頁面需要很長時(shí)間才能完成,那么執(zhí)行前使用 Response.IsClientConnected 如果用戶性急,他們可能會在您開始執(zhí)行他們的請求之前,就會放棄 ASP 頁面。如果他們單擊刷新或移到服務(wù)器上的另一個(gè)頁面,在 ASP 請求隊(duì)列的末尾就有一個(gè)新的請求等候,在隊(duì)列的中間有一個(gè)斷開連接的請求。當(dāng)服務(wù)器的負(fù)載很高時(shí)(因此請求隊(duì)列就會很長,響應(yīng)時(shí)間也會相應(yīng)地變長),就會經(jīng)常發(fā)生這種情況,這樣只能使情況變得更糟。如果用戶不再連接,執(zhí)行 ASP 頁面(特別是慢的、大的 ASP 頁面)已沒有任何意義。您可以使用 Response.IsClientConnected 屬性檢查這一情況。如果它返回 False,則應(yīng)調(diào)用 Response.End 并放棄頁的其余部分。事實(shí)上,IIS 5.0 已將這一做法編為程序 - 每當(dāng) ASP 即將執(zhí)行新請求時(shí),它就會檢查請求在隊(duì)列中已等候了多長時(shí)間。如果已經(jīng)在那里等候了多于 3 秒鐘,ASP 將檢查客戶機(jī)是否仍處于連接狀態(tài),如果沒有連接,就立即終止請求。您可以在配置數(shù)據(jù)庫中使用 AspQueueConnectionTestTime 設(shè)置將超時(shí)時(shí)間由 3 秒調(diào)整為其它值。 如果頁面要花很長時(shí)間才能執(zhí)行完,也可以不時(shí)地檢查 Response.IsClientConnected。當(dāng)啟用了響應(yīng)緩沖時(shí),最好不時(shí)地執(zhí)行 Response.Flush,以用戶知道,正在發(fā)生什么事。 注意 在 IIS 4.0 上,除非先執(zhí)行了 Response.Write,否則 Response.IsClientConnected 就不能正常工作。如果啟用了緩沖,您也必須執(zhí)行 Response.Flush。在 IIS 5.0 上,卻沒有必要這樣做,- Response.IsClientConnected 工作正常。在任何情況下,Response.IsClientConnected 都會有一些開銷,因此只有在一個(gè)操作至少要花(比方說) 500 毫秒(如果您想維持每秒鐘數(shù)十頁的吞吐量,這是一個(gè)很長的時(shí)間)才使用它。經(jīng)驗(yàn)表明,不要每次重復(fù)執(zhí)行緊密循環(huán)時(shí)都調(diào)用它,如顯示表的許多行時(shí) - 每隔二十或五十行調(diào)用一次可能比較合適。 技巧 17:使用 <OBJECT> 標(biāo)記例示對象 如果要引用不在所有代碼路徑(特別是服務(wù)器或應(yīng)用程序作用域的對象)中使用的對象,使用 Global.asa 中 <object runat=server id=objname> 標(biāo)記聲明它們,而不使用 Server.CreateObject 方法。Server.CreateObject 能立即創(chuàng)建對象。如果以后不再使用該對象,您就浪費(fèi)了資源。<object id=objname> 標(biāo)記聲明 objname,但在其方法或?qū)傩缘谝淮问褂靡郧埃粫?chuàng)建 objname。 這又是一個(gè)惰性計(jì)算的例子。 技巧 18:對于 ADO 和其它組件使用 TypeLib 聲明 當(dāng)使用 ADO 時(shí),開發(fā)人員經(jīng)常加入 adovbs.txt,以訪問 ADO 的各種常量。在要使用常量的每個(gè)頁面中必須包含此文件。此常量文件相當(dāng)大,給每個(gè) ASP 頁面的編譯時(shí)間和腳本大小增加了許多系統(tǒng)開銷。 IIS 5.0 引入了綁定到組件類型庫的功能。這可使您引用類型庫一次,并將其用在每個(gè) ASP 頁面上。每個(gè)頁面不會產(chǎn)生編譯常量文件的開銷,且組件開發(fā)人員不必建立 VBScript#_include 文件以在 ASP 上使用。 要訪問 ADO TypeLib,將下面一條語句放在 Global.asa 中。 <!-- METADATA NAME=?Microsoft ActiveX Data Objects 2.5 Library? 或 <!-- METADATA TYPE=?TypeLib?
現(xiàn)今的瀏覽器對一些高級功能如 XML、DHTML、Java 小程序和遠(yuǎn)程數(shù)據(jù)服務(wù)提供支持。盡可能使用這些功能。所有這些技術(shù)都可以執(zhí)行客戶機(jī)端驗(yàn)證和數(shù)據(jù)緩存,免去了到 Web 服務(wù)器的往返。如果您在運(yùn)行一個(gè)智能瀏覽器,那么瀏覽器就能為您進(jìn)行一些驗(yàn)證(例如,在執(zhí)行 POST 之前,檢查信用卡校驗(yàn)和是否有效)。盡可能使用這一功能。通過減少客戶-服務(wù)器之間的往返,可降低 Web 服務(wù)器上的負(fù)載,并能減少網(wǎng)絡(luò)通信量(雖然發(fā)送到瀏覽器的第一個(gè)頁面可能比較大)以及服務(wù)器訪問的任何后端資源。此外,用戶不必像住常一樣讀取新頁,從而用戶的感覺會好一些。這樣做并不意味著您可以不進(jìn)行服務(wù)器端驗(yàn)證 - 您還應(yīng)始終進(jìn)行服務(wù)器端驗(yàn)證。這可以防止由于某種原因(如黑客,或?yàn)g覽器不運(yùn)行客戶機(jī)端驗(yàn)證例程)客戶機(jī)產(chǎn)生錯誤的數(shù)據(jù)。 人們已經(jīng)進(jìn)行了大量的工作,開發(fā)“獨(dú)立于瀏覽器”的 HTML。正是由于這種憂慮,開發(fā)人員不愿再使用流行的瀏覽器功能,但這些功能本可以改善性能。對于一些真正的高性能站點(diǎn),必須關(guān)心瀏覽器“訪問”問題,一個(gè)好的策略是優(yōu)化頁面,使其適應(yīng)流行的瀏覽器。使用瀏覽器功能組件,可以在 ASP 中方便地檢測到瀏覽器功能。Microsoft FrontPage 等工具有助于設(shè)計(jì)適合于瀏覽器和指定 HTML 版本的代碼。參見 When is Better Worse?Weighing the Technology Trade-Offs,以了解更進(jìn)一步的討論。 技巧 20:避免在循環(huán)語句中使用字符串串聯(lián) 許多人在循環(huán)語句中建立一個(gè)字符串,如下所示: s = ?<table>? & vbCrLf 采用這種方法會出現(xiàn)一些問題。第一個(gè)問題是反復(fù)串聯(lián)字符串需要花兩次方的時(shí)間,更通俗地說,運(yùn)行這種循環(huán)語句所花的時(shí)間與記錄數(shù)乘以字段數(shù)所得值的平方成正比。舉一個(gè)更簡單的例子,就可以更清楚地說明這一問題。 s = ?? 在第一次迭代中,您獲得了一個(gè)字符的字符串 ?A?。在第二次迭代中,VBScript 必須重新分配字符串并將兩個(gè)字符 (?AB?) 復(fù)制到 s 中。在第三次迭代中,它還必須再次重新分配 s 并將三個(gè)字符復(fù)制到 s 中。在 N 次(第 26 次)迭代中,它必須重新分配并將 N 個(gè)字符復(fù)制到 s 中??偣簿褪?1+2+3+...+N,即 N*(N+1)/2 次復(fù)制。 在上面的記錄集舉例中,如果有 100 個(gè)記錄和 5 個(gè)字段,內(nèi)循環(huán)將執(zhí)行 100*5 = 500 次,所有的復(fù)制和重新分配所花的時(shí)間與 500*500 = 250,000 成正比。這對于中等大小的記錄集來說復(fù)制操作太多了。 在本例中,代碼可以用 Response.Write() 或內(nèi)嵌腳本 (<% = fld.Value %>) 替代字符串串聯(lián)來改進(jìn)。如果啟用了響應(yīng)緩沖的話(應(yīng)該的),這樣做就會更快,因?yàn)?Response.Write 只將數(shù)據(jù)附加到響應(yīng)緩沖的末尾。并不涉及重新分配,因此效率很高。 在將 ADO 記錄集轉(zhuǎn)換為 HTML 表的特定情況下,應(yīng)考慮使用 GetRows 或 GetString。 如果在 JScript 中串聯(lián)字符串,特別建議使用 += 運(yùn)算符,即,使用 s += ?某字符串?,而不使用 s = s + ?某字符串?。 在默認(rèn)情況下,ASP 禁止在瀏覽器和代理中進(jìn)行緩存。這是有意義的,因?yàn)榫蛯?shí)質(zhì)而言 ASP 頁面是動態(tài)的,上面有隨時(shí)間不斷變化的潛在信息。如果頁面不要求在每個(gè)視圖上進(jìn)行刷新,您應(yīng)啟用瀏覽器和代理緩存。這可使瀏覽器和代理在一定的時(shí)間內(nèi)使用頁面的“緩存”副本,您可以控制時(shí)間的長短。緩存可以大大減輕服務(wù)器上的負(fù)載,縮短用戶的等待時(shí)間。 哪一種動態(tài)頁面可作為要緩存的頁面呢?下面舉一些例子: 天氣預(yù)報(bào)頁面,在此頁面上,每隔 5 分鐘更新一次天氣預(yù)報(bào)。 瀏覽器緩存由 HTTP“過期”報(bào)頭控制,該報(bào)頭由 Web 服務(wù)器發(fā)送給瀏覽器。ASP 提供兩個(gè)簡單的機(jī)制發(fā)送此報(bào)頭。要設(shè)置頁面使其過多少分鐘后到期,則應(yīng)設(shè)置 Response.Expires 屬性。下面的例子告訴瀏覽器內(nèi)容在 10 分鐘內(nèi)過期: <% Response.Expires = 10 %> 若將 Response.Expires 設(shè)置為負(fù)數(shù)或 0,則禁用緩存。一定要使用大的負(fù)數(shù),如 -1000(略多于一天),以避免服務(wù)器和瀏覽器時(shí)鐘之間的不匹配。第二個(gè)屬性 Response.ExpiresAbsolute 將使您設(shè)置內(nèi)容過期的具體時(shí)間: <% Response.ExpiresAbsolute = #May 31,2001 13:30:15# %> 您可以不使用 Response 對象設(shè)置過期時(shí)間,而將 <META> 標(biāo)記寫進(jìn) HTML,通常寫在 HTML 文件的 <HEAD> 部分。一些瀏覽器將遵照此指令,而代理則不然。 <META HTTP-EQUIV=?Expires? VALUE=?May 31,2001 13:30:15?> 最后,您可以使用 Response.CacheControl 屬性,指示其內(nèi)容是否可以讓 HTTP 代理緩存。若將此屬性設(shè)置為“Public”,代理就可以緩存此內(nèi)容。 <% Response.CacheControl = ?Public? %> 在默認(rèn)情況下,此屬性被設(shè)置為“Private”。注意,對于顯示某用戶特定數(shù)據(jù)的頁面,不應(yīng)啟用代理緩存,因?yàn)榇砜赡芙o用戶提供屬于其他用戶的頁面。 #p# 技巧 22:盡可能使用 Server.Transfer 代替 Response.Redirect Response.Redirect 讓瀏覽器請求另一個(gè)頁面。此函數(shù)常用來將用戶重定向到一個(gè)登錄或錯誤頁面。因?yàn)橹囟ㄏ驈?qiáng)制請求新頁面,結(jié)果是瀏覽器必須到 Web 服務(wù)器往返兩次,且 Web 服務(wù)器必須多處理一個(gè)請求。IIS 5.0 引入了一個(gè)新的函數(shù) Server.Transfer,它將執(zhí)行轉(zhuǎn)移到同一臺服務(wù)器上的另一個(gè) ASP 頁。這樣就避免多余的瀏覽器-Web-服務(wù)器的往返,從而改善了總體系統(tǒng)性能以及縮短了用戶的響應(yīng)時(shí)間。檢查“重定向”中的“新的方向”,上面應(yīng)該是 Server.Transfer 和 Server.Execute。 另請參見 Leveraging ASP in IIS 5.0,了解 IIS 5.0 和 ASP 3.0 新功能的完整列表。 技巧 23:在目錄 URL 中使用后斜杠 一個(gè)相關(guān)的技巧是確保在指向目錄的 URL 中使用后斜杠 (/)。如果您省略了后斜杠,瀏覽器就會向服務(wù)器發(fā)出請求,只是為了告訴服務(wù)器,它在請求目錄。瀏覽器就會發(fā)出第二個(gè)請求,將斜杠附加到 URL 后面,只有此后,服務(wù)器才能以該目錄的默認(rèn)文檔或目錄列表(如果沒有默認(rèn)文檔且啟用了目錄瀏覽的話)響應(yīng)。附加斜杠可省去第一個(gè)、無用的住返。為便于用戶閱讀,可以省略顯示名稱中的后斜杠。 例如,寫: <a href=?http://msdn.microsoft.com/workshop/? title=?MSDN Web 這也適用于指向 Web 站點(diǎn)上主頁的 URL:使用下面的:<a href=?http://msdn.microsoft.com/?>,而不使用 <a href=?http://msdn.microsoft.com?>。 技巧 24:避免使用服務(wù)器變量 訪問服務(wù)器變量會使 Web 站點(diǎn)向服務(wù)器發(fā)出一個(gè)特殊請求,并收集所有服務(wù)器變量,而不只是您請求的那個(gè)變量。這種情況類似于,在發(fā)霉的閣樓上,在一個(gè)文件夾中查找某個(gè)文件。當(dāng)您想要找那個(gè)文件時(shí),您必須去閣樓上,先找到文件夾,然后才能找到這份文件。當(dāng)您請求服務(wù)器變量時(shí),發(fā)生的情況是一樣的 - 您第一次請求服務(wù)器變量時(shí),就會使性能受到影響。后面的對其它服務(wù)器變量的請求,則不會對性能產(chǎn)生影響。 決不要訪問非限定的 Request 對象(例如,Request("Data"))。對于不在 Request.Cookies、Request.Form、Request.QueryString 或 Request.ClientCertificate 中的項(xiàng)目,則隱式調(diào)用 Request.ServerVariables。Request.ServerVariables 集合比其它集合慢得多。 技巧 25:升級到最新和最出色的 系統(tǒng)組件是恒定的,我們建議您將它們升級到最新和最好的配置。最好升級到 Windows 2000(因此,也應(yīng)升級到 IIS 5.0、ADO 2.5、MSXML 2.5、Internet Explorer 5.0、VBScript 5.1 和 JScript 5.1)。在多處理器計(jì)算機(jī)上,實(shí)施 IIS 5.0 和 ADO 2.5 可顯著改善性能。在 Windows 2000 下,ASP 可以很好地?cái)U(kuò)展到四個(gè)處理器或更多,而在 IIS 4.0 下,ASP 的擴(kuò)展性不能超出兩個(gè)處理器。在應(yīng)用程序中使用的腳本代碼和 ADO 越多,升級到 Windows 2000 之后,性能的改善就會越多。 如果目前還不能升級到 Windows 2000,您可以升級到 SQL Server、ADO、VBScript 和 JScript、MSXML、Internet Explorer 和 NT 4 Service Packs 的最新版本。它們均可提高性能和可靠性。 技巧 26:優(yōu)化 Web 服務(wù)器 有多種 IIS 優(yōu)化參數(shù)可以改善站點(diǎn)性能。例如,對于 IIS 4.0,我們常常發(fā)現(xiàn),增加 ASP ProcessorThreadMax 參數(shù)(參見 IIS 文檔)可以顯著改善性能,特別是在傾向于等待后端資源(如數(shù)據(jù)庫)或其它中間產(chǎn)品(如屏幕刷)的站點(diǎn)上。在 IIS 5.0 中,您可能發(fā)現(xiàn)啟用 ASP Thread Gating 比查找一個(gè) AspProcessorThreadMax 最佳設(shè)置效率更高,這一點(diǎn)現(xiàn)在已為大家所熟知。 有關(guān)較好的參考資料,參見下面的優(yōu)化 IIS。 最佳的配置設(shè)置取決于(其中一些因素)應(yīng)用程序代碼、運(yùn)行所在的系統(tǒng)硬件和客戶機(jī)工作負(fù)荷。找到最佳設(shè)置的唯一方法是進(jìn)行性能測試,這是我們在下一個(gè)技巧中所要討論的。 技巧 27:進(jìn)行性能測試 正如我們在前面已經(jīng)講過,性能是一個(gè)特征。如果您想要改善站點(diǎn)的性能,那么就制定一個(gè)性能目標(biāo),然后逐步改進(jìn),直到達(dá)到目標(biāo)為止。不要,就不進(jìn)行任何性能測試。通常,在項(xiàng)目結(jié)束時(shí),再作必需的結(jié)構(gòu)調(diào)整已經(jīng)為時(shí)太晚,您的客戶將為此感到失望。將性能測試作為您日常測試的一部分來進(jìn)行??梢詫蝹€(gè)組件分別進(jìn)行性能測試,如針對 ASP 頁或 COM 對象,或?qū)⒄军c(diǎn)作為一個(gè)整體來測試。 許多人使用單個(gè)瀏覽器請求頁面,來測試 Web 站點(diǎn)的性能。這樣做就會給您一個(gè)感覺,即站點(diǎn)的響應(yīng)能力很好,但這樣做實(shí)際上并不能告訴您在負(fù)載條件下站點(diǎn)的性能如何。 一般情況下,要想準(zhǔn)確地測試性能,您需要一個(gè)專門的測試環(huán)境。此環(huán)境應(yīng)包括硬件,其處理器速度、處理器數(shù)量、內(nèi)存、磁盤、網(wǎng)絡(luò)配置等方面與生產(chǎn)環(huán)境的硬件相似。其次,您必須指定客戶機(jī)的工作負(fù)荷:有多少同時(shí)的用戶,他們發(fā)出請求的頻率,他們點(diǎn)擊頁面的類型等等。如果您沒有站點(diǎn)實(shí)際使用情況的數(shù)據(jù),您必須估計(jì)一下使用的情況。最后,您需要一個(gè)可以模擬預(yù)期客戶機(jī)工作負(fù)荷的工具。有了這些工具,您就可以開始回答諸如“如果我有 N 個(gè)同時(shí)的用戶,那么需要多少服務(wù)器?”之類的問題。您還可以找出出現(xiàn)瓶頸的原因,并以此為目標(biāo)進(jìn)行優(yōu)化。 下面列出了一些好的 Web 負(fù)載測試工具。我們特別推薦 Microsoft Web Application Stress (WAS) 工具包。WAS 可使您記錄測試腳本,然后模擬數(shù)百或成千上萬個(gè)用戶訪問 Web 服務(wù)器。WAS 報(bào)告很多統(tǒng)計(jì)信息,包括每秒鐘的請求數(shù),響應(yīng)時(shí)間分布情況和錯誤計(jì)數(shù)。WAS 有豐富的客戶機(jī)界面和基于 Web 的界面兩種,Web 界面可使您進(jìn)行遠(yuǎn)程測試。 一定要閱讀 IIS 5.0 Tuning Guide。 技巧 28:閱讀資源鏈接 下面是一些與性能有關(guān)的出色的資源鏈接。如果您想了解有關(guān)信息,請閱讀 Developing Scalable Web Applications。 資源優(yōu)化 ASP 腳本 Got Any Cache? Nancy Winnick Cluts 著 Maximizing the Performance of Your Active Server Pages,Nancy Winnick Cluts 著 15 Seconds: Performance Section Enhancing Performance in ASP - Part I,Wayne Plourde 著 When is Better Worse? Weighing the Technology Trade-Offs,Nancy Winnick Cluts 著 Speed and Optimization Resources,Charles Carroll 著 優(yōu)化 IIS The Art and Science of Web Server Tuning with Internet Information Services 5.0 Leveraging ASP in IIS 5.0,J.D. Meier 著 Tuning IIS 4.0 for High Volume Sites,Michael Stephenson 著 Tuning Internet Information Server Performance,Mike Moore 著 Navigating the Maze of Settings for Web Server Performance Optimization,Todd Wanke 著 Managing Internet Information Server 4.0 for Performance,Hans Hugli 著 ADO 和 SQL Server Top Ten Tips: Accessing SQL Through ADO and ASP,J.D. Meier 著 Improve the Performance of your MDAC Application,Suresh Kannan 著 Pooling in the Microsoft Data Access Components,Leland Ahlbeck 和 Don Willits 合著 SQL Server: Performance Benchmarks and Guides Improving the Performance of Data Access Components with IIS 4.0,Leland Ahlbeck 著 Microsoft Data Access Components (MDAC) and ActiveX Data Objects (ADO) Performance Tips,Leland Ahlbeck 著 Microsoft SQL Server 7.0 Practical Performance Tuning and Optimization - The Server Perspective,Damien Lindauer 著 Microsoft SQL Server 7.0 Practical Performance Tuning and Optimization - The Application Perspective,Damien Lindauer 著 Accessing Recordsets over the Internet,Dino Esposito 著 ASP 組件和線程模型 ASP Component Guidelines,J.D. Meier 著 Q243548: INFO: Design Guidelines for VB Components under ASP Threading Models Explained,Nancy Winnick Cluts 著 So Happy Together? Using ActiveX components with Active Server Pages,Nancy Winnick Cluts 著 Developing Active Server Components with ATL,George Reilly 著 Agility in Server Components,Neil Allain 著 Building High-Performance Middle-Tier Components with C++,Jon Flanders 著 Active Server Pages and COM Apartments,Don Box 著 House of COM: Active Server Pages,Don Box 著 House of COM: Contexts,Don Box 著 House of COM: Performance Trade-offs of the Windows 2000 Component Execution Environment,Don Box 著 Building COM Components That Take Full Advantage of Visual Basic and Scripting,Ivo Salmre 著 Component Design Principles for MTS 詞典組件 Creating a Page Cache Object,Robert Coleridge 著 Abridging the Dictionary Object: The ASP Team Creates a Lookup-Table Object,Robert Carter 著 Caprock Dictionary Site Server Commerce Edition includes a dictionary component 會話狀態(tài) Q175167: HOWTO: Persisting Values Without Sessions Q157906: HOWTO: How To Maintain State Across Pages with VBScript XML-based Persistence Behaviors Fix Web Farm Headaches,Aaron Skonnard 著 House of COM: Stateless Programming,Don Box 著 性能和擴(kuò)展性 Blueprint for Building Web Sites Using the Microsoft Windows DNA Platform Server Performance and Scalability Killers,George Reilly 著 Microsoft Visual Studio Scalability Center Fitch & Mather Stocks 2000 Tuning the FMStocks Application High-Performance Visual Basic Apps,Ken Spencer 著 Duwamish Books,Phase 4 Top Windows DNA Performance Mistakes and How to Prevent Them,Gary Geiger 和 Jon Pulsipher 合著 Building from Static HTML to High-Performance Web-Farms,Shawn Bice 著 工具 Microsoft Web Application Stress Tool I Can't Stress It Enough -- Load Test Your ASP Application,J.D. Meier 著 Windows DNA Performance Kit Monitoring Events in Distributed Applications Using Visual Studio Analyzer,Mai-lan Tomsen 著 書目 Professional Active Server Pages 3.0,Wrox Press(特別是第 26 章:Optimizing ASP Performance,George Reilly 和 Matthew Gibbs 合著)。 Microsoft Internet Information Services 5.0 Resource Guide(與 Windows 2000 Server Resource Kit 在一起),Microsoft Press。 Microsoft Internet Information Server Resource Kit(用于 IIS 4.0),Microsoft Press。 Programming Distributed Applications with COM and Microsoft Visual Basic 6.0,Ted Pattison 著,Microsoft Press。 Effective COM,Don Box、Keith Brown、Tim Ewald 和 Chris Sells 合著;Addison-Wesley。 Developing Web Usability: The Practice of Simplicity,Jakob Nielsen 著,New Riders。 ASP Web 站點(diǎn) Microsoft TechNet for IIS LearnASP.com 4GuysFromRolla.com 15Seconds.com AspToday.com Asp101.com AspLists.com。許多專業(yè)的郵件列表包括: Fast Code! ASP 樣式 ASP Best Practices,George Reilly 著 ASP Quick Lessons,Charles Carroll 著 Planning for ASP,John Meade 著 ASP Guidelines,J.D. Meier 著 XML Inside XML Performance,Chris Lovett 著 Inside MSXML3 Performance,Chris Lovett 著 該文章在 2011/10/10 9:12:56 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |