ASP動態生成的內容以什么方式輸出效率最高？最好用哪種方法提取數據庫記錄集？本文測試了近20個這類ASP開發中常見的問題，測試工具所顯示的時間告訴我們：這些通常可以想當然的問題不僅值得關注，而且還有出乎意料的秘密隱藏在內。



原文出處：http://www.asptoday.com/articles/20000113.htm

編譯如下：

ASP開發者總是在追求更好的應用性能和可伸縮性。雖然有許多書籍和網站能夠為實現這些目標提供出色的建議，然而，這些建議的根據常常是從ASP工作原理出發所作出的判斷，不能對實際性能的改善程度作任何定量的分析。由于這些建議通常意味著編碼過程的復雜化、降低代碼的可讀性，開發者不能根據ASP應用的性能改善程度評估遵從這些建議所付出的代價是否合理，無法看到實際性能的任何度量。

本文提供一些ASP代碼的性能測試和分析結果，希望能夠幫助ASP開發者了解自己的編碼習慣是否值得在未來的工程中繼續保留，還是有必要修改已有的工程以獲得更好的性能。本文分成兩個部分：在第一部分中，我們考察ASP開發中的一些基本問題；在第二部分中，我們將深入ADO應用優化方面的測試。在測試中我們發現，許多測試結果不僅引人注目，而且可以說是出人意料。

第一部分將回答以下問題：

ASP動態生成的內容以什么方式輸出效率最高？
啟用緩沖對性能的影響有多大？
ASP代碼中注釋對執行效率有何影響？
是否應該顯式設置頁面的默認腳本語言？
如果會話狀態并非必需，是否有必要關閉它？
把代碼放入過程或函數會影響性能嗎？
使用包含文件是否對性能有影響？
實現錯誤控制意味著付出多大的開銷？
設置事務上下文會降低代碼效率嗎？
VBScript Option Explicit對性能有何影響？
測試所用的工具是Microsoft的Web Application Stress Tool（WAST），這是一個免費工具，位于 http://webtool.rte.microsoft.com/。在WAST中，我們利用一個簡單的WAST測試腳本重復地調用下面介紹的測試ASP頁面（每個都超過70000次）。響應時間以平均“直至最后字節的累計時間”為標準（Total Time to Last Byte，TTLB），它的含義是：從第一個請求到測試工具接收到服務器應答數據的最后一個字節之間的時間總和。

測試服務器是196 MB內存的Pentium 166，客戶機是256 MB內存的 Pentium 450。或許有的讀者會認為這些機器的性能不高，不過這并不重要，因為我們不是在測試服務器的能力，而只是利用服務器處理一個頁面所需要的時間來估量腳本執行效率。測試時兩臺機器上沒有運行其他任務。測試用的WAST腳本以及ASP頁面均附于本文后面的ZIP文件內，讀者可以下載它進行同樣的測試。
（出處：熱點網絡）