|
技巧 21：啟用瀏覽器和代理緩存
默認情況下，ASP 禁用瀏覽器和代理中的緩存。這將很有意義，因為 ASP 生來就是動態的，具有潛在地對時間敏感的信息。如果有一個不需要對每次查看進行刷新的頁，則應該啟用瀏覽器和代理緩存。這使得瀏覽器和代理能在某一段時間內，使用某一頁的緩存副本，這時間的長短可以控制。緩存能明顯減輕服務器負荷，使用戶的感受好一些。
哪種動態頁可以緩存？舉例說明：
天氣頁，每 5 分鐘更新一次。
列出新聞的主頁或新聞發布的主頁，每天更新 2 次。
公共基金運營列表，基本的統計數小時更新 1 次。
請注意，使用瀏覽器或代理緩存，只有很少的命中被記錄到 Web 服務器上。如果想精確測量所有頁面查看或者張貼廣告，也許不喜歡使用瀏覽器和代理緩存。
瀏覽器緩存是由 Web 服務器發往瀏覽器的 HTTP 截至期限標題控制的。ASP 提供了兩種發送標題的機制。要將頁面設置為在未來某個分鐘數后過期，請設置 Response.Expires 屬性。以下的例子通知瀏覽器：內容在 10 分鐘后過期：
<% Response.Expires = 10 %>
設置 Response.Expires 為負數或 0 則禁用緩存。一定要使用較大的負數，例如 -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”。注意，不應當為顯示某用戶專用數據的頁啟用代理緩存，因為代理也許為屬于其他用戶的用戶頁面服務。
技巧 22：盡可能使用 Server.Transfer 替代 Response.Redirect
Response.Redirect 通知瀏覽器，請求一個不同的頁面。該函數經常用于重定向用戶到登錄或錯誤頁面。既然重定向強制一個新頁請求，瀏覽器就必須做兩次到 Web 服務器的往返，而且 Web 服務器必須處理額外的請求。IIS 5.0 引入一個新的函數，Server.Transfer，該函數執行傳送到相同服務器上的不同 ASP 頁。這樣避免了額外的、從瀏覽器到 Web 服務器的往返，從而改善了整體系統性能，同時改善了對用戶的響應時間。請查看重定向中的新方向（英文），它討論了 Server.Transfer 和 Server.Execute。
也可以查看Leveraging ASP in IIS 5.0中有關 IIS 5.0 和 ASP 3.0 新功能的完全列表。（英文）
技巧 23：在目錄 URL 尾部加斜線
相關的技巧是，一定要定在指向目錄的 URL 尾部加斜線 (/)。如果省略了斜線，瀏覽器將向服務器提出請求，僅通知它正尋找一個目錄。然后瀏覽器發出第二個請求，在 URL 末尾添加斜線，然后服務器將那個目錄的默認文檔作為響應，或者如果沒有默認文檔并且目錄瀏覽已被啟用，就以目錄列表作為響應。添加了斜線便省去了第一個沒用的往返。出于對用戶的友好，也許想要在顯示的名稱的末尾省略斜線。
例如，寫：
<a href="http://msdn.microsoft.com/workshop/" title="MSDN Web
Workshop">http://msdn.microsoft.com/workshop</a>
它還適用于指向在 Web 站點主頁的 URL：請使用下面的： <a href="http://msdn.microsoft.com/">，不要用 <a href="http://msdn.microsoft.com">.
技巧 24：避免使用服務器變量
訪問服務器變量將引起 Web 站點向服務器提出特殊的請求，然后收集所有的服務器變量，并不止是需要的那個。這好像從發霉的閣樓中的文件夾中檢索某條特殊的信息一樣。當想要某條信息時，在訪問該信息之前必須先上閣樓取得文件夾。這與請求服務器變量時，性能訪問出現第一次請求服務器變量所發生的一樣。后續的對其他服務器變量的訪問不會引起性能訪問。
從不訪問不合格的 Request 對象（例如，Request("Data")）。對于不在 Request.Cookies、Request.Form、Request.QueryString 或 Request.ClientCertificate 中的項，有對 Request.ServerVariables 的隱含調用。Request.ServerVariables 集合比其他集合慢很多。
技巧 25：升級為最新的和最好的版本
系統組件常常升級，建議升級為最新的和最好的版本。最好升級到 Windows 2000（還有，IIS 5.0、ADO 2.5、MSXML 2.5、Internet Explorer 5.0、VBScript 5.1 和 JScript 5.1）。IIS 5.0 和 ADO 2.5 在多處理器計算機上實現了非常好的性能。在 Windows 2000 下，ASP 能良好地擴展到四個處理器或者更多，但是在 IIS 4.0，ASP 不能擴展為超過兩個處理器。在應用程序中使用的腳本和 ADO 越多，升級到 Windows 2000 后獲得的性能提高就越大。
如果您還無法升級到 Windows 2000 ，可以升級為最新版本的 SQL Server、ADO、VBScript 和 JScript、MSXML、Internet Explorer 和 NT 4 Service Packs。它們都改進了性能并增強了可靠性。
技巧 26：調整 Web 服務器
有許多 IIS 調節參數可以改進站點性能。例如，使用 IIS 4.0，我們經常發現增加 ASP 的 ProcessorThreadMax 參數（請參閱 IIS 文檔）能獲得很大的好處，尤其是在經常等待后端資源，例如數據庫或其他中間層產品，例如 screen-scrapers，的站點上。在 IIS 5.0 中也許會發現，打開 ASP Thread Gating 比試圖為 AspProcessorThreadMax 找一個最佳的設置更為有效。
下面的調整 IIS（英文），是一篇很好的資料。
最佳的配置取決于（在其他因素中）應用程序代碼、在其上運行的硬件以及客戶端的工作負荷。發現最佳設置的唯一方法是運行性能測試，它將我們帶入下一個技巧。
技巧 27：進行性能測試
如上所述，性能是一種指標。如果您正努力改進站點的性能，請先設置性能目標，然后提高性能直到達到目標為止。請不要將所有的性能測試放在項目的最后。往往到了項目的最后，再做非做不可的體系結構改動已為時太晚，并使客戶失望。性能測試是日常測試的一部分。性能測試可以針對獨立組件進行，例如 ASP 頁面或 COM 對象，也可以將站點作為一個整體進行。
許多人使用單一的瀏覽器請求頁面來測試他們 Web 站點的性能。這將使您對站點的響應有很好的感覺，但對于站點在有負荷下的性能卻一無所知。
通常，要準確地測量性能，需要專用的測試環境。這個環境應該由那些，在處理器速度、處理器個數、內存、硬盤、網絡配置等方面，能模擬產品硬件的硬件組成。然后，需要定義客戶端的工作負荷：有多少并發用戶；他們提出請求的頻率；他們將訪問的頁面類型等等。如果您無法從站點獲得實際的使用數據，則需要估計它們。最后，需要一個能模擬預期客戶端工作負荷的工具。在這些工具的幫助下，可以開始回答一些問題，例如，如果我有 N 個并發用戶，需要多少臺服務器？您還能找出瓶頸和優化的目標。
下面列出了一些好的 Web 強度測試工具。極力推薦“Microsoft Web 應用程序強度測試 (WAS)”工具包。WAS 允許記錄測試腳本，然后模擬成百或上千個訪問 Web 服務器的用戶。WAS 報告大量統計結果，包括每秒請求數、響應時間的分布和錯誤計數。WAS 具有增強客戶端和基于 Web 的接口；Web 接口允許進行遠程測試。
請務必閱讀 IIS 5.0 調試指南（英文）。
|
