\"＜ TD ＞\" & objRS(\"ShippedDate\") & \"＜ /TD ＞\" & _
\"＜ TD ＞\" & objRS(\"Freight\") & \"＜ /TD ＞\" & _
\"＜ /TR ＞ \" _
)
objRS.MoveNext
Loop
Response.Write(\"＜ /TABLE ＞\")
End If
objRS.Close
objConn.Close
Set objRS = Nothing
Set objConn = Nothing
Response.Write(\"＜ /BODY ＞＜ /HTML ＞\")
% ＞
下面是測試結果：
我們來看一下各欄數字的含義：
0返回0個記錄的頁面所需要的TTLB（毫秒）。在所有的測試中，該值被視為生成頁面本身（包括創建對象）的時間開銷，不包含循環訪問記錄集數據的時間。
25以毫秒計的提取和顯示25個記錄的TTLB
tot time/25\"25\"欄的TTLB除以25，它是每個記錄的總計平均時間開銷。
disp time/25\"25\"欄的TTLB減去\"0\"欄的TTLB，然后除以25。該值反映了在循環記錄集時顯示單個記錄所需時間。
250提取和顯示250個記錄的TTLB。
tot time/250\"250\"欄的TTLB除以25，該值代表單個記錄的總計平均時間開銷。
disp time/250\"250\"欄的TTLB減去\"0\"欄的TTLB，再除以250。該值反映了在循環記錄集時顯示單個記錄所需時間。
上面的測試結果將用來同下一個測試結果比較。
四、是否應該通過包含引用ADOVBS.inc？
Microsoft提供的ADOVBS.inc包含了270行代碼，這些代碼定義了大多數的ADO屬性常量。我們這個示例只從ADOVBS.inc引用了2個常量。因此本次測試（ADO__02.asp）中我們刪除了包含文件引用，設置屬性時直接使用相應的數值。
objRS.CursorType = 0?’ adOpenForwardOnly
objRS.LockType = 1’ adLockReadOnly
可以看到頁面開銷下降了23%。該值并不影響單個記錄的提取和顯示時間，因為這里的變化不會影響循環內的記錄集操作。有多種方法可以解決ADOVBS.inc的引用問題。我們建議將ADOVBS.inc文件作為參考，設置時通過注釋加以說明。請記住，正如第一部分所指出的，適度地運用注釋對代碼的效率影響極小。另外一種方法是將那些需要用到的常量從ADOVBS.inc文件拷貝到頁面內。
還有一個解決該問題的好方法，這就是通過鏈接ADO類型庫使得所有的ADO常量直接可用。把下面的代碼加入Global.asa文件，即可直接訪問所有的ADO常量：
＜ !--METADATA TYPE=\"typelib\"
FILE=\"C:Program FilesCommon FilesSYSTEMADOmsado15.dll\"
NAME=\"ADODB Type Library\" -- ＞
或者：
＜ !--METADATA TYPE=\"typelib\" UUID=\"00000205-0000-0010-8000-00AA006D2EA4\"
NAME=\"ADODB Type Library\" -- ＞
因此，我們的第一條規則為：
避免包含ADOVBS.inc文件，通過其他方法訪問和使用ADO常量。
五、使用記錄集時是否應該創建單獨的連接對象？
要正確地回答這個問題，我們必須分析兩種不同條件下的測試：第一，頁面只有一個數據庫事務；第二，頁面有多個數據庫事務。
在前例中，我們創建了一個單獨的Connection對象并將它賦給Recordset的ActiveConnection屬性。然而，如ADO__03.asp所示，我們也可以直接把連接串賦給ActiveConnection屬性，在腳本中初始化和配置Connection對象這一額外的步驟可以省去。
objRS.ActiveConnection = Application(\"Conn\")
雖然Recordset對象仍舊要創建一個連接，但此時的創建是在高度優化的條件下進行的。因此，與上一次測試相比，頁面開銷又下降了23%，而且如預期的一樣，單個記錄的顯示時間沒有實質的變化。
因此，我們的第二個規則如下：
如果只使用一個記錄集，直接把連接串賦給ActiveConnection屬性。
接下來我們檢查頁面用到多個記錄集時，上述規則是否仍舊有效。為測試這種情形，我們引入一個FOR循環將前例重復10次。在這個測試中，我們將研究三種變化：
第一，如ADO__04.asp所示，在每一個循環中建立和拆除Connection對象：
文章來源于領測軟件測試網 http://www.kjueaiud.com/
