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

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

ASP 選項 

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

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

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

COM 選項 

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

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

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

怎么辦？ 

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

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

技巧 10：顯式使用選項 

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

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

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

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

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

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

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

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

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

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

變量 
Foo 
被解析為全局變量。 
變量 
bar 
被解析為 
Foo. 
的成員。這將產生 COM 方法調用。 
變量 
blah 
被解析為 
Foo.bar 
的成員。這也將產生 COM 方法調用。 
變量 
qaz 
被解析為 
foo.bar.blah 
的成員。是的，這也將產生 COM 方法調用。 
調用 
Foo.bar.blah.quaz(1) 
。又一次產生 COM 方法調用。理解這幅圖了嗎？ 
執(zhí)行步驟 1 到 3 將再次解析 
baz 
。系統(tǒng)不知道調用 
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ù)組。從關心性能的角度來說，如果計算機受物理內存的限制，最好一開始將數(shù)組的維數(shù)設置為最差方案 - 而不要將維數(shù)設置為最佳方案，再根據(jù)需要重新定義維數(shù)。這并不意味著明知道不需要那么多而就是應該分配太多的內存。 

下面代碼展示了您沒有必要地使用了 
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ù)組為正確的大?。ū纠袨?nbsp;5），而不是 
Redim 
數(shù)組，再加大數(shù)組。這可能會浪費一點兒內存（如果沒有用盡所有元素），但是獲得的是速度。 

技巧 14：使用響應緩沖 

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

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

<% Response.Buffer = True %> 

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

Response.Flush 

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

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

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

技巧 15：批處理內嵌腳本和 Response.Write 語句 

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

下面是更有效的代碼，每行中有一個對響應流的寫入。所有代碼均包含在一個 VBScript 塊內： 

<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> 

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

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

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

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

如果有某頁執(zhí)行了很長時間，您可能還想按一定的時間間隔檢查 
Response.IsClientConnected 
。在啟用響應緩沖之后，按一定的時間間隔執(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)的每次迭代中調用它，例如當繪制表中的行，可能每 20 行或每 50 行調用一次。 

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

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

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

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

當使用 ADO 時，開發(fā)人員經常包含 
adovbs.txt 
來獲得對 ADO 不同常量的訪問權。該文件必須包含在要使用這些常量的每一頁中。該常量文件非常大，給每個 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ù)服務。請盡量利用這些功能。所有這些技術，都可以通過執(zhí)行客戶端的驗證和數(shù)據(jù)緩存，減少了與 Web 服務器之間的往返。如果您正在運行智能瀏覽器，該瀏覽器可以為您進行一些驗證（例如，在運行 POST 之前檢查信用卡的校驗和否有效）。重申一次，請盡量使用這些功能。由于削減了客戶端到服務器的往返路程，將減少對 Web 服務器的壓力，并且削減了網絡通信量（雖然發(fā)送給瀏覽器的初始頁面可能更大），服務器訪問的所有后端資源也削減了。而且用戶不必經常提取新頁，使用戶的感受好一些。這并不減輕對服務器端驗證的需要。還是應該經常進行服務器端的驗證。這樣能夠防止由于某些原因從客戶端來的壞數(shù)據(jù)，例如黑客，或者不運行客戶端驗證程序的瀏覽器。 

許多站點由獨立于瀏覽器創(chuàng)建的 HTML 組成。這一點經常阻礙開發(fā)人員利用可以提高性能的流行瀏覽器功能。對于真正高性能的、必須關心瀏覽器的站點，良好的策略是針對流行的瀏覽器優(yōu)化您的頁面。在 ASP 中使用"瀏覽器性能組件"，很容易檢測到瀏覽器的功能。諸如 Microsoft FrontPage 等工具，能幫助您設計使用所希望的目標瀏覽器和 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 

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

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

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

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

，并復制三個字符到 

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

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

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

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

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

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

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

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

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

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

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

<% Response.Expires = 10 %> 

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

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

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

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

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

<% Response.CacheControl = "Public" %> 

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

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

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

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

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

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

例如，寫： 

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

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


技巧 24：避免使用服務器變量 

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

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

最新評論