技巧 9：進程外的執(zhí)行將犧牲可靠性 

ASP 和 MTS/COM+ 都有允許您以可靠性換取性能的配置選項。當建立和部署應(yīng)用程序時，應(yīng)當理解這種交換。 

ASP 選項 

ASP 應(yīng)用程序可以配置為以三種方式之一運行。在 IIS 5.0 中引入了術(shù)語"隔離級"來描述這些選項。三個隔離級值分別是低、中和高： 

低級隔離。該隔離級在所有版本的 IIS 中受到支持，并且是最快的。它在主 IIS 進程 Inetinfo.exe 中執(zhí)行 ASP。如果 ASP 應(yīng)用程序崩潰，則 IIS 也將崩潰。（要在 IIS 4.0 下重新啟動 IIS，Web 站點管理員需要使用工具，如 InetMon，來監(jiān)視站點，如果服務(wù)器失敗，將運行批處理文件來重新啟動服務(wù)器。而 IIS 5.0 則引入了可靠的重新啟動，它將自動重新啟動失敗的服務(wù)器。） 
中級隔離。IIS 5.0 引入了這個新隔離級，它稱為進程外的，這是因為 ASP 運行在 IIS 進程之外。在中級隔離中，所有被配置按"中級"運行的 ASP 應(yīng)用程序，將共享單個進程空間。這將減少在一個服務(wù)器上運行多個進程外的 ASP 應(yīng)用程序所需的進程數(shù)。中級是 IIS 5.0 中默認的隔離級。 
高級隔離。在 IIS 4.0 和 IIS 5.0 中受到支持，高級隔離也是進程外的。如果 ASP 崩潰，則 Web 服務(wù)器并不崩潰。ASP 應(yīng)用程序?qū)⒃谙乱粋€ ASP 請求時自動重新啟動。使用高級隔離，每個被配置為按高級運行的 ASP 應(yīng)用程序，將在其自己的進程空間中運行。這樣可以保護 ASP 應(yīng)用程序彼此不受干擾。它的缺點是它需要為每個 ASP 應(yīng)用程序建立獨立的進程。當需要在一個服務(wù)器上主持十多個應(yīng)用程序時，會增加很多開銷。 
那么，哪個選項是最好的呢？在 IIS 4.0 中，運行進程外的應(yīng)用程序會極大地影響性能。在 IIS 5.0 中，做了許多工作，使得進程外運行 ASP 應(yīng)用程序?qū)π阅墚a(chǎn)生的影響降到了最低。實際上，在大多數(shù)測試中，在 IIS 5.0 中的 ASP 進程外應(yīng)用程序，要比 IIS 4.0 中的進程內(nèi)應(yīng)用程序運行得更快。無論如何，進程內(nèi)（低隔離級）在兩種平臺上仍然產(chǎn)生了最好的性能。但是，如果您的命中率相對較低或最大吞吐量較低，選擇低隔離級不會有太大的好處。所以，除非您需要每個 Web 服務(wù)器每秒處理數(shù)百或數(shù)千個頁面，否則沒有必要選擇低隔離級。同樣，應(yīng)當測試多種配置并判斷哪種情形最適合您。 

注意： 當您進程外運行 ASP 應(yīng)用程序（中級或高級隔離）時，則在 NT4 上它們將運行在 MTS 中，而在 Windows 2000 上它們將運行在 COM+ 中。即，在 NT4 上它們運行在 Mtx.exe 中，而在 Windows 2000 上它們運行在 DllHost.exe 中。在"任務(wù)管理器"中，您可以看見這些正在運行的進程。還可以看見 IIS 如何為進程外的 ASP 應(yīng)用程序配置 MTS 程序包或 COM+ 應(yīng)用程序。 

COM 選項 

COM 組件也有三個配置選項，雖然與 ASP 選項不完全相似。COM 組件可以被："不配置"、配置為"庫應(yīng)用程序"或配置為"服務(wù)器應(yīng)用程序"。"不配置"是指不向 COM+ 注冊組件。組件將運行在調(diào)用者的進程空間，就是說，它們是"進程中"的。"庫應(yīng)用程序"也是進程中的，但受惠于 COM+ 的服務(wù)，包括安全性、事務(wù)和環(huán)境支持。"服務(wù)器應(yīng)用程序"被配置為在其自己的進程空間中運行。 

您可能看到，不配置的組件比庫應(yīng)用程序優(yōu)點稍微多些。您還可能看到"庫應(yīng)用程序"比"服務(wù)器應(yīng)用程序"有很大的性能優(yōu)點。這是因為"庫應(yīng)用程序"與 ASP 運行在同一個進程中，而"服務(wù)器應(yīng)用程序"則運行在自己的進程中。內(nèi)部進程調(diào)用的開銷要比進程內(nèi)調(diào)用的開銷大得多。而且，當在進程之間傳遞數(shù)據(jù)（如記錄集）時，必須在兩個進程之間復(fù)制所有的數(shù)據(jù)。 

缺點！當使用"COM 服務(wù)器應(yīng)用程序"時，如果要在 ASP 和 COM 之間傳遞對象，請確保對象實現(xiàn)"按值匯集"，即 MBV。實現(xiàn) MBV 的對象將其自身從一個進程復(fù)制到另一個進程。這比另一種方式好，在另一種方式中，對象留在創(chuàng)建它的進程中，而其他進程則重復(fù)調(diào)用創(chuàng)建使用該對象的進程。被斷開連接的 ADO 記錄集將是按值匯集的，已連接的記錄集則不是。Scripting.Dictionary 并不實現(xiàn) MBV，不會在進程之間傳遞。最后，要另外告訴 VB 程序員的是：MBV 不是通過傳遞參數(shù) 
ByVal 
獲得的。MBV 是由原始組件創(chuàng)作者實現(xiàn)的。 

怎么辦？ 

如果您想要以性能與可靠性的合理交換來完成您的配置，我們的推薦如下： 

在 IIS 4.0 上，使用 ASP 的低隔離級別，并使用"MTS 服務(wù)器包"。 
在 IIS 5.0 上，使用 ASP 的中隔離級別，并使用"COM+ 庫應(yīng)用程序"。 
這些是很一般的準則；通常讓公司以中或高隔離級別運行 ASP，而單一目的的 Web 服務(wù)器可運行于低隔離級別。請權(quán)衡折中并自行決定滿足需求的配置。 

技巧 10：顯式使用選項 

在 .asp 文件中顯式使用 
選項 Explicit 
。置于 .asp 文件開頭的這一指令，強制開發(fā)人員聲明所有要使用的變量。許多開發(fā)人員認為這有助于調(diào)試應(yīng)用程序，因為它避免了錯誤鍵入變量名稱而不經(jīng)意地新建變量（例如， 
MyXLMString=... 
而非 
MyXMLString=) 
。 

也許更重要的是，聲明的變量比未聲明的變量快。實際上，腳本運行時，在每次使用未聲明變量時按照名稱引用。而聲明的變量，在編譯或運行時分配了序號。這樣，聲明的變量按照該序號引用。由于 
選項 Explicit 
強制變量聲明，因此保證聲明了所有變量而實現(xiàn)快速訪問。 

技巧 11：在子例程和函數(shù)中使用局部變量 

局部變量是在子例程和函數(shù)中聲明的變量。在子例程和函數(shù)中，局部變量訪問要快于全局變量訪問。使用局部變量還可以使代碼更加清晰，因此盡可能使用局部變量。 

技巧 12：將常用數(shù)據(jù)復(fù)制到腳本變量 

在 ASP 中訪問 COM 時，應(yīng)該將常用的對象數(shù)據(jù)復(fù)制到腳本變量中。這將削減 COM 方法的調(diào)用，COM 方法的調(diào)用與訪問腳本變量相比，要相對昂貴些。在訪問 Collection 和 Dictionary 對象時，這一技術(shù)也可以削減了昂貴的查找。 

通常，如果打算多次訪問對象數(shù)據(jù)，請將數(shù)據(jù)放入腳本變量。該優(yōu)化的主要目標是 Request 變量（Form 和 QueryString 變量）。例如，您的站點可能傳遞一個名為 UserID 的 QueryString。假定該 UserID 變量要在特定頁中引用 12 次。請不要調(diào)用 
Request("UserID") 
12 次，而在 ASP 頁的開頭將 UserID 賦予某個變量。然后就在頁中使用該變量。這將節(jié)省 11 次 COM 方法調(diào)用。 

在實際中，訪問 COM 屬性或方法暗藏著繁復(fù)的過程和大量的開銷。下面是一個示例，它只是些相當普通的代碼（從語法上講）： 

Foo.bar.blah.baz = Foo.bar.blah.qaz(1) 
If Foo.bar.blah.zaq = Foo.bar.blah.abc Then ' ... 

在運行這段代碼時，將發(fā)生下列事件： 

變量 
Foo 
被解析為全局變量。 
變量 
bar 
被解析為 
Foo. 
的成員。這將產(chǎn)生 COM 方法調(diào)用。 
變量 
blah 
被解析為 
Foo.bar 
的成員。這也將產(chǎn)生 COM 方法調(diào)用。 
變量 
qaz 
被解析為 
foo.bar.blah 
的成員。是的，這也將產(chǎn)生 COM 方法調(diào)用。 
調(diào)用 
Foo.bar.blah.quaz(1) 
。又一次產(chǎn)生 COM 方法調(diào)用。理解這幅圖了嗎？ 
執(zhí)行步驟 1 到 3 將再次解析 
baz 
。系統(tǒng)不知道調(diào)用 
qaz 
是否更改對象模型，因此步驟 1 到 3 必須再次執(zhí)行解析 
baz 
。 
將 
baz 
解析為 
Foo.bar.blah 
的成員。進行屬性置入。 
再次執(zhí)行步驟 1 到 3 并解析 
zaq 
。 
再次執(zhí)行步驟 1 到 3 并解析 
abc 
。 
正如所見，這是非?？膳碌牡托剩ǘ曳浅Ｂ?。用 VBScript 編寫該代碼實現(xiàn)的快速方法為： 

Set myobj = Foo.bar.blah ' 對 blah 做一次解析 
Myobj.baz = myobj.qaz(1) 
If Myobj.zaq = Myobj.abc Then '... 

如果您使用的是 VBScript 5.0 或更高版本，則可用 
With 
語句來寫這段代碼： 

With Foo.bar.blah 
.baz = .qaz(1) 
If .zaq = .abc Then '... 
... 
End With 

請注意該技巧對 VB 編程同樣有效。 

技巧 13：避免重新定義數(shù)組 

盡量避免 
Redim 
數(shù)組。從關(guān)心性能的角度來說，如果計算機受物理內(nèi)存的限制，最好一開始將數(shù)組的維數(shù)設(shè)置為最差方案 - 而不要將維數(shù)設(shè)置為最佳方案，再根據(jù)需要重新定義維數(shù)。這并不意味著明知道不需要那么多而就是應(yīng)該分配太多的內(nèi)存。 

下面代碼展示了您沒有必要地使用了 
Dim 
和 
Redim 
來解決。 

<% 
Dim MyArray() 
Redim MyArray(2) 
MyArray(0) = "hello" 
MyArray(1) = "good-bye" 
MyArray(2) = "farewell" 
... 
' 一些別的代碼中，這里您不需要更多的空間，然后 ... 
Redim Preserve MyArray(5) 
MyArray(3) = "more stuff" 
MyArray(4) = "even more stuff" 
MyArray(5) = "yet more stuff" 
%> 

更好的辦法是只須一開始 
Dim 
數(shù)組為正確的大小（本例中為 5），而不是 
Redim 
數(shù)組，再加大數(shù)組。這可能會浪費一點兒內(nèi)存（如果沒有用盡所有元素），但是獲得的是速度。 

技巧 14：使用響應(yīng)緩沖 

您可以通過打開"響應(yīng)緩沖區(qū)"來緩沖值得輸出的整個頁。這將寫入瀏覽器的數(shù)據(jù)量降為最小，從而提高總體性能。每次寫入都會有大量開銷（包括 IIS 和通過電纜發(fā)送的數(shù)據(jù)量），因此寫入的越少越好。TCP/IP 的工作效率，在發(fā)送少量大的數(shù)據(jù)塊時明顯高于發(fā)送大量小的數(shù)據(jù)塊時，原因在于它的低速啟動和 Nagling 算法（用于最小化網(wǎng)絡(luò)阻塞）。 

打開響應(yīng)緩沖有兩種方法。第一種，可以使用"Internet 服務(wù)管理器"為整個應(yīng)用程序打開響應(yīng)緩沖。這是推薦的方法，在 IIS 4.0 和 IIS 5.0 中，在默認情況下，為新的 ASP 應(yīng)用程序打開響應(yīng)緩沖。第二種，逐頁將下列代碼行放在 ASP 頁的開頭，從而啟用響應(yīng)緩沖： 

<% Response.Buffer = True %> 

該行代碼必須在任何響應(yīng)數(shù)據(jù)寫入瀏覽器之前執(zhí)行（也就是說，在任何 HTML 出現(xiàn)在 ASP 腳本中之前和任何 Cookies 被使用 
Response.Cookies 
集合設(shè)置之前）。通常，最好是為整個應(yīng)用程序打開響應(yīng)緩沖。這允許省略上面每頁中的代碼行。 

Response.Flush 

響應(yīng)緩沖的通病是用戶感覺 ASP 頁響應(yīng)遲鈍（盡管總體響應(yīng)時間改善了），因為他們需要等到整個頁生成后才能看見該頁。對于長時間運行的頁面，可以通過設(shè)置 
Response.Buffer = False 
關(guān)閉響應(yīng)緩沖。但是，更好的策略是使用 
Response.Flush 
方法。該方法刷新由 ASP 繪入瀏覽器的所有 HTML。例如，繪制了具有 1,000 行的表的 100 行后，ASP 可以調(diào)用 
Response.Flush 
強制將結(jié)果繪制到瀏覽器；這允許用戶在其余的行準備好之前先看到頭 100 行。該技術(shù)給了您兩個舉世無雙的好東西 - 響應(yīng)緩沖與瀏覽器中數(shù)據(jù)的逐步顯示的組合。 

（注意，在上面 1,000 行表的示例中，許多瀏覽器，在看到 </table> 結(jié)束標記之前不會開始繪制表。請檢查目標瀏覽器的支持性。要解決該問題，請將表分割為具有較少行的多個表，然后在每個表后面調(diào)用 
Response.Flush 
。新版本的 Internet Explorer 將在表完全下載之前繪制表，特別是如果指定表的列寬則繪制速度更快；這避免強制 Internet Explorer 通過度量每個單元格的內(nèi)容來計算列寬。） 

響應(yīng)緩沖的另一個通病是在生成大型頁時將使用服務(wù)器的大量內(nèi)存。對于該問題，除了要求生成大型頁的技巧外，還可以通過巧妙地使用 
Response.Flush 
來解決。 

技巧 15：批處理內(nèi)嵌腳本和 Response.Write 語句 

VBScript 語法 
<% = expression %> 
將" 
表達式 
"的值寫入 ASP 輸出流。如果響應(yīng)緩沖沒有打開，則這些語句的每一句都會導(dǎo)致通過網(wǎng)絡(luò)，以許多小型包的形式，向瀏覽器寫入數(shù)據(jù)。這是非常慢的。另外，解釋少量腳本和 HTML，將導(dǎo)致在腳本引擎和 HTML 之間切換，也降低了性能。因此，請使用下面技巧：用對 
Response.Write 
的一個調(diào)用，替換內(nèi)嵌的密集組合表達式。例如，在下面范例中，每行每字段有一個對響應(yīng)流的寫入，每行都有許多 VBScript 和 HTML 之間的切換： 

<table> 
<% For Each fld in rs.Fields %> 
<th><% = fld.Name %></th> 
<% 
Next 
While Not rs.EOF 
%> 
<tr> 
<% For Each fld in rs.Fields %> 
<td><% = fld.value %></td> 
<% Next 
</tr> 
<% rs.MoveNext 
Wend %> 
</table> 

下面是更有效的代碼，每行中有一個對響應(yīng)流的寫入。所有代碼均包含在一個 VBScript 塊內(nèi)： 

<table> 
<% 
For each fld in rs.Fields 
Response.Write ("<th>" & fld.Name & "</th>" & vbCrLf) 
Next 
While Not rs.EOF 
Response.Write ("<tr>") 
For Each fld in rs.Fields %> 
Response.Write("<td>" & fld.value & "</td>" & vbCrLf) 
Next 
Response.Write "</tr>" 
Wend 
%> 
</table> 

當響應(yīng)緩沖被禁用時，本技巧的作用更大。最好啟用響應(yīng)緩沖，然后觀察批處理 
Response.Write 
是否對性能有幫助。 

（在這一特例中，構(gòu)建表的主體的嵌套循環(huán) ( 
While Not rs.EOF... 
) 可以被精心構(gòu)造的、對 GetString 的調(diào)用所替代。） 

技巧 16：在開始長時間的任務(wù)之前先使用 Response.IsClientConnected 

如果用戶失去耐心，他們可以在開始執(zhí)行他們的請求之前放棄 ASP 頁。如果他們單擊了 Refresh 或跳轉(zhuǎn)到服務(wù)器的其他頁上，在 ASP 請求隊列的末尾將有一個新的請求，而在隊列的中間有一個斷開連接的請求。這通常發(fā)生在服務(wù)器處于高負荷的情況下（它有一個很長的請求隊列，相應(yīng)的響應(yīng)時間也很長），這只能使情況更糟。如果用戶不再連接，將沒有執(zhí)行 ASP 頁的點（特別是低速、重量級的 ASP 頁）?？梢允褂?nbsp;
Response.IsClientConnected 
屬性檢查這種情況。如果它返回 
False 
，則應(yīng)調(diào)用 
Response.End 
并放棄該頁的剩余內(nèi)容。實際上，每當 ASP 要執(zhí)行新的請求時，IIS 5.0 便將該方法編碼，來檢查隊列中的請求有多長。如果在那里超過了 3 秒鐘，ASP 會檢查客戶是否仍然連接著，如果客戶已斷開連接，就立即結(jié)束該請求。您可以使用 metabase 中的 
AspQueueConnectionTestTime 
設(shè)置，調(diào)整這 3 秒的超時時間。 

如果有某頁執(zhí)行了很長時間，您可能還想按一定的時間間隔檢查 
Response.IsClientConnected 
。在啟用響應(yīng)緩沖之后，按一定的時間間隔執(zhí)行 
Response.Flush 
，告訴用戶正在進行的是哪些事情，是個好辦法。 

注意 在 IIS 4.0 中， 
Response.IsClientConnected 
將不能正常工作，除非首先執(zhí)行 
Response.Write 
。如果啟用了緩沖，也需要執(zhí)行 
Response.Flush 
。在 IIS 5.0 中則不必如此 - 
Response.IsClientConnected 
工作得很好。在任何情況下， 
Response.IsClientConnected 
都要有些開銷，所以，只有在執(zhí)行至少要用 500 毫秒（如果想維持每秒幾十頁的吞吐量，這是一個很長的時間了）的操作前才使用它。作為通常的規(guī)則，不要在緊密循環(huán)的每次迭代中調(diào)用它，例如當繪制表中的行，可能每 20 行或每 50 行調(diào)用一次。 

技巧 17：使用 <OBJECT> 標記實例化對象 

如果需要引用不能在所有代碼路徑中使用的對象（尤其是服務(wù)器 - 或應(yīng)用程序 - 作用域的對象），則使用 Global.asa 中的 
<object runat=server id=objname> 
標記來聲明它們，而不是使用 
Server.createObject 
方法。 
Server.createObject 
立刻創(chuàng)建對象。如果以后不使用那個對象，就不要浪費資源。 
<object id=objname> 
標記聲明了 objname，但實際上 objname 此時并沒有創(chuàng)建，直到它的方法或?qū)傩缘谝淮伪皇褂脮r才創(chuàng)建。 

這是遲緩計算的另一個例子。 

技巧 18：使用 ADO 對象和其他組件的 TypeLib 聲明 

當使用 ADO 時，開發(fā)人員經(jīng)常包含 
adovbs.txt 
來獲得對 ADO 不同常量的訪問權(quán)。該文件必須包含在要使用這些常量的每一頁中。該常量文件非常大，給每個 ASP 頁增加了很多編譯時間和腳本大小方面的開銷。 

IIS 5.0 提供了綁定到組件類型庫的能力。允許您在每個 ASP 頁上引用一次類型庫并使用它。每頁不需要為編譯常量文件付出代價，并且組件開發(fā)人員不必為在 ASP 中的使用而生成 VBScript #include 文件。 

要訪問 ADO 類型庫，請將下列語句之一放入 Global.asa 中。 

<!-- METADATA NAME="Microsoft ActiveX Data Objects 2.5 Library" 
TYPE="TypeLib" UUID="{00000205-0000-0010-8000-00AA006D2EA4}" --> 

或者 

<!-- METADATA TYPE="TypeLib" 
FILE="C:\Program Files\Common Files\system\ado\msado15.dll" --> 

技巧 19：利用瀏覽器的驗證能力 

流行的瀏覽器具有對以下功能的高級支持，例如 XML、DHTML、Java 小程序以及遠程數(shù)據(jù)服務(wù)。請盡量利用這些功能。所有這些技術(shù)，都可以通過執(zhí)行客戶端的驗證和數(shù)據(jù)緩存，減少了與 Web 服務(wù)器之間的往返。如果您正在運行智能瀏覽器，該瀏覽器可以為您進行一些驗證（例如，在運行 POST 之前檢查信用卡的校驗和否有效）。重申一次，請盡量使用這些功能。由于削減了客戶端到服務(wù)器的往返路程，將減少對 Web 服務(wù)器的壓力，并且削減了網(wǎng)絡(luò)通信量（雖然發(fā)送給瀏覽器的初始頁面可能更大），服務(wù)器訪問的所有后端資源也削減了。而且用戶不必經(jīng)常提取新頁，使用戶的感受好一些。這并不減輕對服務(wù)器端驗證的需要。還是應(yīng)該經(jīng)常進行服務(wù)器端的驗證。這樣能夠防止由于某些原因從客戶端來的壞數(shù)據(jù)，例如黑客，或者不運行客戶端驗證程序的瀏覽器。 

許多站點由獨立于瀏覽器創(chuàng)建的 HTML 組成。這一點經(jīng)常阻礙開發(fā)人員利用可以提高性能的流行瀏覽器功能。對于真正高性能的、必須關(guān)心瀏覽器的站點，良好的策略是針對流行的瀏覽器優(yōu)化您的頁面。在 ASP 中使用"瀏覽器性能組件"，很容易檢測到瀏覽器的功能。諸如 Microsoft FrontPage 等工具，能幫助您設(shè)計使用所希望的目標瀏覽器和 HTML 版本的代碼。更詳細的討論，請查看 When is Better Worse? Weighing the Technology Trade-Offs（英文）。 

技巧 20：在循環(huán)中避免字符串串聯(lián) 

許多人在循環(huán)中創(chuàng)建類似這樣的字符串： 

s = "<table>" & vbCrLf 
For Each fld in rs.Fields 
s = s & " <th>" & fld.Name & "</th> " 
Next 

While Not rs.EOF 
s = s & vbCrLf & " <tr>" 
For Each fld in rs.Fields 
s = s & " <td>" & fld.value & "</td> " 
Next 
s = s & " </tr>" 
rs.MoveNext 
Wend 

s = s & vbCrLf & "</table>" & vbCrLf 
Response.Write s 

這種方法有幾個問題。首先，重復(fù)連接字符串所花費的時間，以二次方曲線的速率增長；粗略地計算，運行循環(huán)所花費的時間，與記錄數(shù)乘以字段數(shù)的平方成正比。舉一個簡單的例子，便能清楚地說明這一點。 

s = "" 
For i = Asc("A") to Asc("Z") 
s = s & Chr(i) 
Next 

在第一次迭代中，得到一個字符的字符串 
"A" 
。在第二次迭代中，VBScript 必須重新分配字符串并復(fù)制兩個字符 
"AB" 
到 

。在第三次迭代中，它必須再次重新分配 

，并復(fù)制三個字符到 

。在第 N 次（26 次）迭代中，它必須重新分配并復(fù)制 N 個字符到 

。就是 1+2+3+...+N 的和，為 N*(N+1)/2 次復(fù)制。 

在以上記錄集的例子中，如果有 100 條記錄和 5個字段，則內(nèi)部的循環(huán)將執(zhí)行 100*5 = 500 次，并且完成所有復(fù)制和重新分配所花費時間，將與 500*500 = 250,000 成正比。對一個大小適度的記錄集，將有很多次復(fù)制。 

在該例子中，代碼可以改進：字符串的連接將被 
Response.Write() 
或內(nèi)嵌腳本 ( 
<% = fld.value %> 
) 所替代。如果打開響應(yīng)緩沖，這個操作將會很快，因為 
Response.Write 
僅僅將數(shù)據(jù)添加到響應(yīng)緩沖的末尾。不再重新分配，因而非常有效。 

特別是在將 ADO 記錄集轉(zhuǎn)換到 HTML 表時，請考慮使用 GetRows 或 GetString。 

如果用 JScript 連接字符串，強烈建議使用 
+= 
操作符；即用 
s += "某字符串"， 
而不是 
s = s + "某字符串" 
。 

技巧 21：啟用瀏覽器和代理緩存 

默認情況下，ASP 禁用瀏覽器和代理中的緩存。這將很有意義，因為 ASP 生來就是動態(tài)的，具有潛在地對時間敏感的信息。如果有一個不需要對每次查看進行刷新的頁，則應(yīng)該啟用瀏覽器和代理緩存。這使得瀏覽器和代理能在某一段時間內(nèi)，使用某一頁的緩存副本，這時間的長短可以控制。緩存能明顯減輕服務(wù)器負荷，使用戶的感受好一些。 

哪種動態(tài)頁可以緩存？舉例說明： 

天氣頁，每 5 分鐘更新一次。 
列出新聞的主頁或新聞發(fā)布的主頁，每天更新 2 次。 
公共基金運營列表，基本的統(tǒng)計數(shù)小時更新 1 次。 
請注意，使用瀏覽器或代理緩存，只有很少的命中被記錄到 Web 服務(wù)器上。如果想精確測量所有頁面查看或者張貼廣告，也許不喜歡使用瀏覽器和代理緩存。 

瀏覽器緩存是由 Web 服務(wù)器發(fā)往瀏覽器的 HTTP 截至期限標題控制的。ASP 提供了兩種發(fā)送標題的機制。要將頁面設(shè)置為在未來某個分鐘數(shù)后過期，請設(shè)置 
Response.Expires 
屬性。以下的例子通知瀏覽器：內(nèi)容在 10 分鐘后過期： 

<% Response.Expires = 10 %> 

設(shè)置 
Response.Expires 
為負數(shù)或 0 則禁用緩存。一定要使用較大的負數(shù)，例如 -1000 （大于一天），來克服服務(wù)器時鐘和瀏覽器時鐘之間的差異。第二個屬性 
Response.ExpiresAbsolute 
，允許設(shè)置內(nèi)容過期的指定時間： 

<% Response.ExpiresAbsolute = #May 31,2001 13:30:15# %> 

如果不想使用 Response 對象設(shè)置過期時間，可以將 <META> 標記寫入 HTML，通常寫在 HTML 文件的 <HEAD> 內(nèi)部。一些瀏覽器會響應(yīng)這條指令，但代理不會。 

<META HTTP-EQUIV="Expires" value="May 31,2001 13:30:15"> 

最后，可以標識內(nèi)容對 HTTP 代理緩存是否有效，請使用 
Response.CacheControl 
屬性。設(shè)置屬性為"Public"，允許代理緩存內(nèi)容。 

<% Response.CacheControl = "Public" %> 

默認情況下，該屬性設(shè)置為"Private"。注意，不應(yīng)當為顯示某用戶專用數(shù)據(jù)的頁啟用代理緩存，因為代理也許為屬于其他用戶的用戶頁面服務(wù)。 

技巧 22：盡可能使用 Server.Transfer 替代 Response.Redirect 

Response.Redirect 
通知瀏覽器，請求一個不同的頁面。該函數(shù)經(jīng)常用于重定向用戶到登錄或錯誤頁面。既然重定向強制一個新頁請求，瀏覽器就必須做兩次到 Web 服務(wù)器的往返，而且 Web 服務(wù)器必須處理額外的請求。IIS 5.0 引入一個新的函數(shù)， 
Server.Transfer 
，該函數(shù)執(zhí)行傳送到相同服務(wù)器上的不同 ASP 頁。這樣避免了額外的、從瀏覽器到 Web 服務(wù)器的往返，從而改善了整體系統(tǒng)性能，同時改善了對用戶的響應(yīng)時間。請查看重定向中的新方向（英文），它討論了 
Server.Transfer 
和 
Server.Execute 
。 

也可以查看Leveraging ASP in IIS 5.0中有關(guān) IIS 5.0 和 ASP 3.0 新功能的完全列表。（英文） 

技巧 23：在目錄 URL 尾部加斜線 

相關(guān)的技巧是，一定要定在指向目錄的 URL 尾部加斜線 
(/) 
。如果省略了斜線，瀏覽器將向服務(wù)器提出請求，僅通知它正尋找一個目錄。然后瀏覽器發(fā)出第二個請求，在 URL 末尾添加斜線，然后服務(wù)器將那個目錄的默認文檔作為響應(yīng)，或者如果沒有默認文檔并且目錄瀏覽已被啟用，就以目錄列表作為響應(yīng)。添加了斜線便省去了第一個沒用的往返。出于對用戶的友好，也許想要在顯示的名稱的末尾省略斜線。 

例如，寫： 

<a href="http://msdn.microsoft.com/workshop/&quo ... uot;MSDN Web 
Workshop">http://msdn.microsoft.com/workshop</a> 

它還適用于指向在 Web 站點主頁的 URL：請使用下面的： <a >. 


技巧 24：避免使用服務(wù)器變量 

訪問服務(wù)器變量將引起 Web 站點向服務(wù)器提出特殊的請求，然后收集所有的服務(wù)器變量，并不止是需要的那個。這好像從發(fā)霉的閣樓中的文件夾中檢索某條特殊的信息一樣。當想要某條信息時，在訪問該信息之前必須先上閣樓取得文件夾。這與請求服務(wù)器變量時，性能訪問出現(xiàn)第一次請求服務(wù)器變量所發(fā)生的一樣。后續(xù)的對其他服務(wù)器變量的訪問不會引起性能訪問。 

從不訪問不合格的 Request 對象（例如， 
Request("Data") 
）。對于不在 
Request.Cookies 
、 
Request.Form 
、 
Request.QueryString 
或 
Request.ClientCertificate 
中的項，有對 
Request.ServerVariables 
的隱含調(diào)用。 
Request.ServerVariables 
集合比其他集合慢很多。

最新評論