在本文的第一部分中，我回顾了有关ASP开发的一些基本问题，介绍了一些性能测试的结果，以理解我们放置在页面中的代码可能对运行性能造成什么样的影响。在这个系列的第二部分，我们将探讨经过论证的ASP最广泛的用途，即通过ActiveX 数据对象(ADO)交互使用数据库内容。ADO是Microsoft通用并简单的数据库界面。

　　ADO有很多的功能设置，因此准备这篇文章时最大的挑战便是限制测试问题的范围。考虑到读取大数据集会为web 服务器施加很大的负载，我决定将研究的内容局限在为使用ADO记录集寻找最优化配置的方面。但是这个限制还是提出了一个挑战，因为ADO为执行同一个功能提供了多种方式。比如说，记录集可以从Recordset 类中恢复，也可以从Connection和Command 类中恢复。另外，一旦你有了一个记录集，那么有很多个选择会戏剧性地影响性能。因此，同第一部分一样，我将尽可能地多涉及一些具体问题。

目的
　　我研究的目的是获取足够的信息以找到以下问题的答案：

　　* 是否应该使用ADOVBS.inc包含文件?

　　* 当使用一个记录集时，是否应该创建一个单独的Connection对象?

　　* 恢复一个记录集最好的方法是什么?

　　* 指针和锁的类型中，哪些是最有效的?

　　* 是否应该使用断开的记录集?

　　* 设置记录集（Recordset）属性的最好方法是什么?

　　* 引用记录集中域值的最有效方法是什么?

　　* 使用临时字符串可以较好地代替缓冲器吗？

测试是如何设立的？
　　为进行这项研究中的测试，我们共组装了21个ASP页面（包含在本文下载内容中）。每个页面都被配置成用3个不同的查询返回记录集运行，这些记录集中分别有0、25、250条记录。这可以帮助我们将装载记录集的问题和在记录集中循环上的性能问题隔离开。

　　为满足这些变化的条件，数据库连接字符串和测试SQL字符串都作为应用程序变量存储在Global.asa中。因为我们的测试数据库是在Microsoft SQL Server 7.0上运行的，因此我们的连接字符串指定OLEDB作为连接供应者、Northwind 样本数据库（包含在SQL服务器中）作为当前数据库。SQL SELECT语句要求Northwind Orders 表格中的7个特定域。

　　< SCRIPT LANGUAGE=VBScript RUNAT=Server >

　　Sub Application_OnStart

　　Application("Conn") = "Provider=SQLOLEDB; " & _

　　"Server=MyServer; " & _

　　"uid=sa; " & _

　　"pwd=;" & _

　　"DATABASE=northwind"

　　Application("SQL") = "SELECT TOP 0 OrderID, " & _

　　" CustomerID, " & _

　　" EmployeeID, " & _

　　" OrderDate, " & _

　　" RequiredDate, " & _

　　" ShippedDate, " & _

　　" Freight " & _

　　"FROM [Orders] "

　　End Sub

　　< /SCRIPT >

　　'alternate sql ?25 records

　　Application("SQL") = "SELECT TOP 25 OrderID, " & _

　　" CustomerID, " & _

　　" EmployeeID, " & _

　　" OrderDate, " & _

　　" RequiredDate, " & _

　　" ShippedDate, " & _

　　" Freight " & _

　　"FROM [Orders] "

　　'alternate sql ?250 records

　　Application("SQL") = "SELECT TOP 250 OrderID, " & _

　　" CustomerID, " & _

　　" EmployeeID, " & _

　　" OrderDate, " & _

　　" RequiredDate, " & _

　　" ShippedDate, " & _

　　" Freight " & _

　　"FROM [Orders] "

　　我们的测试服务器是一个双450 MHz Pentium ，512MB的RAM，在其上运行着NT Server 4.0 SP5, MDAC 2.1 (数据访问组件)以及Microsoft Scripting Engine的5.0版本。SQL服务器在一个同样规格的单独机器上运行。同第一篇文章一样，我使用Microsoft的Web应用程序重点工具记录从最初的页面请求到传输最后一个字节（TTLB ）的时间，精确到服务器上的毫秒级。这个测试脚本运行20小时，调用每个页面1300次以上。显示的时间是session的平均TTLB。要记住的是，同第一篇文章一样，我们只是试图涉及性能方面的问题，而非伸缩性和容量的问题。

　　还请注意，我们在服务器上开启了缓冲器。另外，我把所有的文件名都定为同样长度，因此文件名中就会有一个或多个下划线来衬垫。

开始
　　在第一个测试中，我们使用典型Microsoft ASP ADO 样本文件中的典型场景来恢复一个简单的记录集。在这个例子( ADO__01.asp )中,我们首先创建一个Connection对象，然后创建一个Recordset对象。当然，我在脚本中进行了一些修改，以反映在本系列的第一部分中涉及到的一些好的做法。

　　< % Option Explicit % >

　　< !-- #Include file="ADOVBS.INC" -- >

　　< %

　　Dim objConn

　　Dim objRS

　　Response.Write( _

　　"< HTML >< HEAD >" & _

　　"< TITLE >ADO Test< /TITLE >" & _

　　"< /HEAD >< BODY >" _

　　)

　　Set objConn = Server.CreateObject("ADODB.Connection")

　　objConn.Open Application("Conn")

　　Set objRS = Server.CreateObject("ADODB.Recordset")

　　objRS.ActiveConnection = objConn

　　objRS.CursorType = adOpenForwardOnly

　　objRS.LockType = adLockReadOnly

　　objRS.Open Application("SQL")

　　If objRS.EOF Then

　　Response.Write("No Records Found")

　　Else

　　'write headings

　　Response.Write( _

　　"< TABLE BORDER=1 >" & _

　　"< TR >" & _

　　"< TH >OrderID< /TH >" & _

　　"< TH >CustomerID< /TH >" & _

　　"< TH >EmployeeID< /TH >" & _

　　"< TH >OrderDate< /TH >" & _

　　"< TH >RequiredDate< /TH >" & _

　　"< TH >ShippedDate< /TH >" & _

　　"< TH >Freight< /TH >" & _

　　"< /TR >" _

　　)

　　'write data

　　Do While Not objRS.EOF

　　Response.Write( _

　　"< TR >" & _

　　"< TD >" & objRS("OrderID") & "< /TD >" & _

　　"< TD >" & objRS("CustomerID") & "< /TD >" & _

　　"< TD >" & objRS("EmployeeID") & "< /TD >" & _

　　"< TD >" & objRS("OrderDate") & "< /TD >" & _

　　"< TD >" & objRS("RequiredDate") & "< /TD >" & _

　　"< 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 TTLB除以25条记录（毫秒）。代表每条记录的总平均时间。

　　disp time/25 以毫秒计的TTLB减去“0”那栏的TTLB，并除以25条记录。代表在记录集中循环显示每条记录的时间。

　　250 装载并显示250条记录的TTLB（毫秒）。

　　tot time/250 TTLB除以250条记录（毫秒）。代表每条记录的总平均时间。

　　disp time/250 以毫秒计的TTLB减去“0”那栏的TTLB，并除以250条记录。代表在记录集中循环显示每条记录的时间。

　　我们将用下面测试的结果与这些值相比较。

是否应该使用ADOVBS.inc 包含文件？
　　这个问题我想快点解决。Microsoft 提供的ADOVBS.inc 文件包含270行代码，代表可以应用于ADO属性的大部分常量。我们的例子中只引用了这个文件中的2个常量。因此对于这个测试( ADO__02.asp )，我取消了包含文件的引用，并用属性列举中的实际数字代替了常量。

　　objRS.CursorType = 0 ' adOpenForwardOnly

　　objRS.LockType = 1 ' adLockReadOnly

　　我们可以看到装载时间减少了23%。这与每条记录的显示时间有定义上的不同，因为这种改变对于在记录集中循环不应该有影响。这个问题有几种解决办法。我建议使用ADOVBS.inc 文件作为参考，必要时使用注释来注明数字。要记住，就如同在第一部分所阐明的一样，注释是不需要惧怕的，因为只要使用适度，它们不会给性能带来大的影响。另一种方法是只从文件中将你所需要的常量复制到页面中。

　　解决这个问题有一个很酷的方法，通过将ADO类库连接到你的应用程序，使所有的ADO常量都可用。将以下代码增加到你的Global.asa 文件，你就可以直接使用所有的常量。

　　< !--METADATA TYPE="typelib"

　　FILE="C:\Program Files\Common Files\SYSTEM\ADO\msado15.dll"

　　NAME="ADODB Type Library" -- >

　　或

　　< !--METADATA TYPE="typelib"

　　UUID="00000205-0000-0010-8000-00AA006D2EA4"

　　NAME="ADODB Type Library" -- >

　　所以，这里是我们的第一个规则:

　　* 避免包含ADOVBS.inc文件，用其它方法来使用常量。