技巧 19: 利用瀏覽器的驗證功能 現今的瀏覽器對一些高級功能如 xml、DHTML、java 小程序和遠程數據服務提供支持。盡可能使用這些功能。所有這些技術都可以執行客戶機端驗證和數據緩存，免去了到 Web 服務器的往返。如果您在運行一個智能瀏覽器，那么瀏覽器就能為您進行一些驗證（例如，在執行 POST 之前，檢查信用卡校驗和是否有效）。盡可能使用這一功能。通過減少客戶-服務器之間的往返，可降低 Web 服務器上的負載，并能減少網絡通信量（雖然發送到瀏覽器的第一個頁面可能比較大）以及服務器訪問的任何后端資源。此外，用戶不必像住常一樣讀取新頁，從而用戶的感覺會好一些。這樣做并不意味著您可以不進行服務器端驗證 - 您還應始終進行服務器端驗證。這可以防止由于某種原因（如黑客，或瀏覽器不運行客戶機端驗證例程）客戶機產生錯誤的數據。人們已經進行了大量的工作，開發“獨立于瀏覽器”的 HTML。正是由于這種憂慮，開發人員不愿再使用流行的瀏覽器功能，但這些功能本可以改善性能。對于一些真正的高性能站點，必須關心瀏覽器“訪問”問題，一個好的策略是優化頁面，使其適應流行的瀏覽器。使用瀏覽器功能組件，可以在 asp 中方便地檢測到瀏覽器功能。Microsoft FrontPage 等工具有助于設計適合于瀏覽器和指定 HTML 版本的代碼。參見 When is Better Worse？Weighing the Technology Trade-Offs，以了解更進一步的討論。 技巧 20：避免在循環語句中使用字符串串聯 許多人在循環語句中建立一個字符串，如下所示： 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 & ? *lt;/tr>? rs.MoveNext Wend s = s & vbCrLf & ?</table>? & vbCrLf Response.Write s 采用這種方法會出現一些問題。第一個問題是反復串聯字符串需要花兩次方的時間，更通俗地說，運行這種循環語句所花的時間與記錄數乘以字段數所得值的平方成正比。在將 ADO 記錄集轉換為 HTML 表的特定情況下，應考慮使用 GetRows 或 GetString。如果在 JScript 中串聯字符串，特別建議使用 += 運算符，即，使用 s += ?某字符串?，而不使用 s = s + ?某字符串?。 技巧 21：啟用瀏覽器和代理緩存 在默認情況下，ASP 禁止在瀏覽器和代理中進行緩存。這是有意義的，因為就實質而言ASP 頁面是動態的，上面有隨時間不斷變化的潛在信息。如果頁面不要求在每個視圖上進行刷新，您應啟用瀏覽器和代理緩存。這可使瀏覽器和代理在一定的時間內使用頁面的“緩存”副本，您可以控制時間的長短。緩存可以大大減輕服務器上的負載，縮短用戶的等待時間。 哪一種動態頁面可作為要緩存的頁面呢？ 注意，在使用瀏覽器或代理緩存的情況下，Web 服務器上記錄的訪問次數減少了。如果您想準確地測量所有頁面視圖或張帖公布，您就不希望使用瀏覽器和代理緩存。瀏覽器緩存由 HTTP“過期”報頭控制，該報頭由 Web 服務器發送給瀏覽器。ASP 提供兩個簡單的機制發送此報頭。要設置頁面使其過多少分鐘后到期，則應設置 Response.Expires 屬性。 技巧 22：盡可能使用 Server.Transfer 代替 Response.Redirect Response.Redirect 讓瀏覽器請求另一個頁面。此函數常用來將用戶重定向到一個登錄Response.Redirect 讓瀏覽器請求另一個頁面。此函數常用來將用戶重定向到一個登錄或錯誤頁面。因為重定向強制請求新頁面，結果是瀏覽器必須到 Web 服務器往返兩次，且 Web 服務器必須多處理一個請求。IIS 5.0 引入了一個新的函數 Server.Transfer，它將執行轉移到同一臺服務器上的另一個 ASP 頁。這樣就避免多余的瀏覽器-Web-服務器的往返，從而改善了總體系統性能以及縮短了用戶的響應時間。檢查“重定向”中的“新的方向”，上面應該是 Server.Transfer 和 Server.Execute。 技巧 23：在目錄 URL 中使用后斜杠 一個相關的技巧是確保在指向目錄的 URL 中使用后斜杠 (/)。如果您省略了后斜杠，瀏覽器就會向服務器發出請求，只是為了告訴服務器，它在請求目錄。瀏覽器就會發出第二個請求，將斜杠附加到 URL 后面，只有此后，服務器才能以該目錄的默認文檔或目錄列表（如果沒有默認文檔且啟用了目錄瀏覽的話）響應。附加斜杠可省去第一個、無用的住返。為便于用戶閱讀，可以省略顯示名稱中的后斜杠。 技巧 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 文檔）可以顯著改善性能，特別是在傾向于等待后端資源（如數據庫）或其它中間產品（如屏幕刷）的站點上。在 IIS 5.0 中，您可能發現啟用 ASP Thread Gating 比查找一個 AspProcessorThreadMax 最佳設置效率更高，這一點現在已為大家所熟知。 最佳的配置設置取決于（其中一些因素）應用程序代碼、運行所在的系統硬件和客戶機工作負荷。找到最佳設置的唯一方法是進行性能測試. 技巧 27：進行性能測試 正如我們在前面已經講過，性能是一個特征。如果您想要改善站點的性能，那么就制定一個性能目標，然后逐步改進，直到達到目標為止。不要，就不進行任何性能測試。通常，在項目結束時，再作必需的結構調整已經為時太晚，您的客戶將為此感到失望。將性能測試作為您日常測試的一部分來進行?？梢詫蝹€組件分別進行性能測試，如針對ASP 頁或 COM 對象，或將站點作為一個整體來測試。許多人使用單個瀏覽器請求頁面，來測試 Web 站點的性能。這樣做就會給您一個感覺，即站點的響應能力很好，但這樣做實際上并不能告訴您在負載條件下站點的性能如何。 一般情況下，要想準確地測試性能，您需要一個專門的測試環境。此環境應包括硬件，其處理器速度、處理器數量、內存、磁盤、網絡配置等方面與生產環境的硬件相似。其次，您必須指定客戶機的工作負荷：有多少同時的用戶，他們發出請求的頻率，他們點擊頁面的類型等等。如果您沒有站點實際使用情況的數據，您必須估計一下使用的情況。最后，您需要一個可以模擬預期客戶機工作負荷的工具。有了這些工具，您就可以開始回答諸如“如果我有 N 個同時的用戶，那么需要多少服務器？”之類的問題。您還可以找出出現瓶頸的原因，并以此為目標進行優化。
