什么才是提高ASP性能的最佳选择（续一）

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

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

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

　　* 是否应该使用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的平均T
TLB。要记住的是，同第一篇文章一样，我们只是试图涉及性能方面的问题，而非伸缩性和容
量的问题。

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

开始

　　在第一个测试中，我们使用典型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 FilesCommon FilesSYSTEMADOmsado15.dll"
　　NAME="ADODB Type Library" -- >

　　或

　　< !--METADATA TYPE="typelib"
　　UUID="00000205-0000-0010-8000-00AA006D2EA4"
　　NAME="ADODB Type Library" -- >

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

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

 

 

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

　　要想正确回答这个问题，需要在两个不同情况下检验测试结果：第一是每页执行一个数
据库处理的情况，第二是每页执行多个数据库处理的情况。

　　在前面的例子中，我们已经创建了一个单独的Connection对象，并将它传递到记录集的
ActiveConnection 属性。但是也有可能仅仅把连接字符串传递到这个属性中，从而可以避免
一个额外的步骤，即在脚本( ADO__03.asp )中例示和配置一个单独的组件：

　　objRS.ActiveConnection = Application("Conn")

　　尽管我们仍然在记录集中创建了一个连接，但它是在非常优化的情况下创建的，所以刚
一开始我们就看到启动时间比以前的测试减少了23%，同预料中一样，同每个记录的显示时间
几乎没有什么差别。

　　因此，我们的第二个规则是：

　　* 当使用一个单个记录集时，将连接字符串传递到ActiveConnection属性中。

　　下面要确定当在一个页面上创建多个记录集时，这个逻辑是否依然成立。为测试这个情
况，我引入了FOR 循环，将前面的例子重复10次。在这个测试中，我们还将研究3种选择：

　　第一，我们在每个循环中创建并销毁Connection 对象( ADO__04.asp ):

　　Dim i
　　For i = 1 to 10
　　Set objConn = Server.CreateObject("ADODB.Connection")
　　objConn.Open Application("Conn")
　　Set objRS = Server.CreateObject("ADODB.Recordset")
　　objRS.ActiveConnection = objConn
　　objRS.CursorType = 0 'adOpenForwardOnly
　　objRS.LockType = 1 'adLockReadOnly
　　objRS.Open Application("SQL")
　　If objRS.EOF Then
　　Response.Write("No Records Found")
　Else
　　'write headings
　　...
　　'write data
　　...
　　End If
　　objRS.Close
　　Set objRS = Nothing
　　objConn.Close
　　Set objConn = Nothing
　　Next

　　第二，在循环外创建一个单独的Connection 对象，并与每个记录集共享它( ADO__05.a
sp ):

　　Set objConn = Server.CreateObject("ADODB.Connection")
　　objConn.Open Application("Conn")
　　Dim i
　　For i = 1 to 10
　　Set objRS = Server.CreateObject("ADODB.Recordset")
　　objRS.ActiveConnection = objConn
　　objRS.CursorType = 0 'adOpenForwardOnly
　　objRS.LockType = 1 'adLockReadOnly
　　objRS.Open Application("SQL")
　　If objRS.EOF Then
　　Response.Write("No Records Found")
　　Else
　　'write headings
　　...
　　'write data
　　...
　　End If
　　objRS.Close
　　Set objRS = Nothing
　　Next
　　objConn.Close
　　Set objConn = Nothing

　　第三，在每个循环中将连接字符串传递到ActiveConnection 属性( ADO__06.asp ):

　　Dim i
　　For i = 1 to 10
　　Set objRS = Server.CreateObject("ADODB.Recordset")
　objRS.ActiveConnection = Application("Conn")
　　objRS.CursorType = 0 'adOpenForwardOnly
　　objRS.LockType = 1 'adLockReadOnly
　　objRS.Open Application("SQL")
　　If objRS.EOF Then
　　Response.Write("No Records Found")
　　Else
　　'write headings
　　...
　　'write data
　　...
　　End If
　　objRS.Close
　　Set objRS = Nothing
　　Next

　　你可能已经猜到了，在每个循环中创建并销毁Connection 对象是一个低效率的方法。但
是令人吃惊的是，仅仅在每个循环中传递连接字符串比共享单一连接对象的效率只低一点点
。

　　尽管如此，我们的第3条规则是：

　　* 在一个页面上使用多个记录集时，创建一个Connection 对象，在ActiveConnection
属性中重复使用它。

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

　　到目前为止，我们所有测试都只用了只向前（Forward Only ）的指针在记录集中循环。
但是，ADO还为记录集提供了3种类型的指针：Static, Dynamic 和 Keyset。每一种都提供了
额外的功能，比如向前和向后移动以及当别人建立数据时可以看到修改情况的功能。不过，
讨论这些指针类型的内涵不是本文讨论的范围。我把这些留给你自己。下面是各种类型的比
较分析。

　　与它们的同类Forward Only 相比，这些额外的指针都明显地造成了更大的负载( ADO__
03.asp )。另外这些指针在循环期间也更慢。我想与你一起分享的一条忠告是要避免这种想
法：“我不时地需要一下Dynamic 指针，所以干脆总是用它算了。”

　　从本质上说，同样的问题也适用于锁的类型。前面的测试中只使用了Read Only（只读）
类型的锁。但是，还有三种类型的锁：Lock Pessimistic、 Lock Optimistic和Lock Batch
 Optimistic。同指针的选择一样，这些锁也为处理记录集中的数据提供了额外的功能和控制
。同样，我将学习每种锁设置的适当用途的内容留给你自己。

　　所以引导我们考虑规则4的逻辑很简单：使用最适合你的任务的最简单的指针和锁的类型
。

获取一个记录集最好的方式是什么？

　　到目前为止，我们只是通过Recordset 对象来恢复记录集。但是ADO还提供了一些获取记
录集的间接方法。下一个测试就将ADO__03.asp 中的值与直接从一个Connection对象中创建
一个记录集对象( CONN_01.asp )来比较。

　　Set objConn = Server.CreateObject("ADODB.Connection")
　　objConn.Open Application("Conn")
　　Set objRS = objConn.Execute(Application("SQL"))

　　我们看到，负载有一个轻微的增加，显示每条记录的时间没有变化。

　　然后，我们看看从一个Command 对象中直接创建一个Recordset 对象( CMD__01.asp ):
 

　　Set objCmd = Server.CreateObject("ADODB.Command")
　　objCmd.ActiveConnection = Application("Conn")
　　objCmd.CommandText = Application("SQL")
　　Set objRS = objCmd.Execute

　　我们再次看到负载有一个轻微的增加，每个记录的显示时间有一个名义上的区别。虽然
最后这两种方法对性能的影响很小，却有一个大问题需要考虑。

　　通过Recordset 类创建一个记录集对于控制如何处理记录集提供了最大的灵活性。虽然
其它方法也没有提出一个压倒性的性能问题，但是你会被默认状态下返回何种指针类型和锁
类型而困惑，这些对于你的特定需求来说不一定是最优的。

　　所以，除非因为某种特殊原因你需要其它方法的话，请遵循第5条规则：通过ADODB.Rec
ordset 类例示记录集以获得最好的性能和最大的灵活性。

是否应该断开记录集？

　　ADO为断开一个记录集提供了一种选择，记录集要在一个向前查询中恢复所有数据、关闭
连接、使用一个本地（或客户）指针在数据集中移动。这还提供了一个早期释放连接的机会
。这种情况对于处理远程数据服务是必要的，因为这种情况下数据必须从数据库断开。但是
对于普通的用途，这样做有好处吗？

　　下面我们增加了CursorLocation 属性，打开记录集后关闭连接( CLIENT1.asp ):

　　Set objRS = Server.CreateObject("ADODB.Recordset")
　　objRS.CursorLocation = 3 ' adUseClient
　　objRS.ActiveConnection = Application("Conn")
　　objRS.LockType = 1 ' adLockReadOnly
　　objRS.Open Application("SQL")
　　objRS.ActiveConnection = Nothing

　　从理论上说，这个技术应该导致性能更快。原因有两个：首先，在记录集中移动时，避
免了通过连接的重复请求；其次通过较早地取消连接减轻了资源需求。但是，在使用客户端
指针时，效率低得很明显。可能是由于当使用客户指针位置时，不管你的设置是什么，Curs
orType 都被修改成Static。

　　规则6是这样的：除非是一个断开的环境中所要求的，避免使用断开的记录集。

什么是设置记录集属性的最好方法？

　　前面所有的测试都是通过单独的属性设置来直接设置记录集的属性的。但是Recordset.
Open 函数可以为我们所需要的全部属性接收额外的参数。虽然对于每个属性来说，单独的代
码行易于阅读和维护，它们还是要分别执行一个单独函数调用，必须通过COM界面来集合( A
DO__07.asp ):

　　Set objRS = Server.CreateObject("ADODB.Recordset")
　　objRS.Open Application("SQL"), Application("Conn"), 0, 1
　　' adForwardOnly, adLockReadOnly

　　这些方法在负载上带来得差别小得惊人，于是我们得到规则7：不要对单独设置记录集属
性感到担心。

 

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

　　到目前为止，我都是用名字引用记录集中的域值的。这可能是一种效率很低的方法，因
为每次调用都需要查找域。为了证明这一点，下面的测试就要通过记录集中域的集合的指针
来引用域(ADO__08.asp):

　'write data
　Do While Not objRS.EOF
　　Response.Write( _
　　"< TR >" & _
　　"< TD >" & objRS(0) & "< /TD >" & _
　　"< TD >" & objRS(1) & "< /TD >" & _
　　"< TD >" & objRS(2) & "< /TD >" & _
　　"< TD >" & objRS(3) & "< /TD >" & _
　　"< TD >" & objRS(4) & "< /TD >" & _
　　"< TD >" & objRS(5) & "< /TD >" & _
　　"< TD >" & objRS(6) & "< /TD >" & _
　　"< /TR > " _
　　)
　　objRS.MoveNext
　Loop

　　正如我们所预料的，装载时间的变化很小（差异可能是由于代码上的轻微减少引起的）
。但是这种技术在有效显示时间上却带来了明显的减少。

　　在下面的例子中，我们将给每个域指定一个单独的变量。这种方法避免了在表格循环内
的所有查找( ADO__09.asp ):

　If objRS.EOF Then
　　Response.Write("No Records Found")
　Else
　　'write headings
　　...
　　Dim fld0
　　Dim fld1
　　Dim fld2
　　Dim fld3
　　Dim fld4
　　Dim fld5
　　Dim fld6
　　Set fld0 = objRS(0)
　　Set fld1 = objRS(1)
　　Set fld2 = objRS(2)
　　Set fld3 = objRS(3)
　　Set fld4 = objRS(4)
　　Set fld5 = objRS(5)
　　Set fld6 = objRS(6)
　　'write data
　　Do While Not objRS.EOF
　　Response.Write( _
　　"< TR >" & _
　　"< TD >" & fld0 & "< /TD >" & _
　　"< TD >" & fld1 & "< /TD >" & _
　　"< TD >" & fld2 & "< /TD >" & _
　　"< TD >" & fld3 & "< /TD >" & _
　　"< TD >" & fld4 & "< /TD >" & _
　　"< TD >" & fld5 & "< /TD >" & _
　　"< TD >" & fld6 & "< /TD >" & _
　　"< /TR >" _
　　)
　　objRS.MoveNext
　　Loop
　　Set fld0 = Nothing
　　Set fld1 = Nothing
　　Set fld2 = Nothing
　　Set fld3 = Nothing
　　Set fld4 = Nothing
　　Set fld5 = Nothing
　　Set fld6 = Nothing
　　Response.Write("< /TABLE >")
　End If

　　到目前，这种方法形成的结果是最好的。每条记录的显示时间下降成了.45 毫秒。

　　现在，所有测试脚本的配置都要求对结果记录集有一些了解。比如说，我们一直在栏标
题中给域名编码，单独地引用这些域的值。下面的例子提供了一个动态的解决方案，在域的
集合中循环，不仅得到数据，也得到域的标题（ADO__10.asp ):

　If objRS.EOF Then
　　Response.Write("No Records Found")
　Else
　　'write headings
　　Response.Write("< TABLE BORDER=1 >< TR >")
　　For Each objFld in objRS.Fields
　　Response.Write("< TH >" & objFld.name & "< /TH >")
　　Next
　　Response.Write("< /TR >")
　　'write data
　　Do While Not objRS.EOF
　　Response.Write("< TR >")
　　For Each objFld in objRS.Fields
　　Response.Write("< TD >" & objFld.value & "< /TD >")
　　Next
　　Response.Write("< /TR >")
　　objRS.MoveNext
　　Loop
　　Response.Write("< /TABLE >")
　End If

　可以看到，我们在性能上有一个损失，但是这个方法还是比ADO__07.asp要快一些。

　　下面的测试是在最后两个测试之间进行一些折中。通过在一个动态分配数组中保存域的
引用，既维持了动态的灵活性，也挽回了一些性能上的损失。

　If objRS.EOF Then
　　Response.Write("No Records Found")
　Else
　　Dim fldCount
　　fldCount = objRS.Fields.Count
　　Dim fld()
　　ReDim fld(fldCount)
　　Dim i
　　For i = 0 to fldCount-1
　　Set fld(i) = objRS(i)
　　Next
　　'write headings
　　Response.Write("< TABLE BORDER=1 >< TR >")
　　For i = 0 to fldCount-1
　　Response.Write("< TH >" & fld(i).name & "< /TH >")
　　Next
　　Response.Write("< /TR >")
　　'write data
　　Do While Not objRS.EOF
　　Response.Write("< TR >")
　　For i = 0 to fldCount-1
　　Response.Write("< TD >" & fld(i) & "< /TD >")
　　Next
　　Response.Write("< /TR >")
　　objRS.MoveNext
　　Loop
　　For i = 0 to fldCount-1
　　Set fld(i) = Nothing
　　Next
　　Response.Write("< /TABLE >")
　End If

　　虽然它并不比最好值快，但是比前面的几个例子要快了很多，并且有一个优势就是能够
动态地表现任何记录集。

　　在下一个测试中，我们将对以前的方案做一个彻底的改变，使用记录集的GetRows指令创
建一个循环用的数组，而不是在记录集本身进行循环。注意，调用GetRows之后，立刻就将记
录集设置为Nothing，这样就能更快地释放系统资源。另外还要注意数组的第一个维数代表域
，第二个维数代表行 ( ADO__12.asp ):

　If objRS.EOF Then
　　Response.Write("No Records Found")
　　objRS.Close
　　Set objRS = Nothing
　Else
　　'write headings
　　...
　　'set array
　　Dim arrRS
　　arrRS = objRS.GetRows
　　'close recordset early
　　objRS.Close
　　Set objRS = Nothing
　　'write data
　　Dim numRows
　　Dim numFlds
　　Dim row
　　Dim fld
　　numFlds = Ubound(arrRS, 1)
　　numRows = Ubound(arrRS, 2)
　　For row= 0 to numRows
　　Response.Write("< TR >")
　　For fld = 0 to numFlds
　　Response.Write("< TD >" & arrRS(fld, row) & "< /TD >")
　　Next
　　Response.Write("< /TR >")
　　Next
　　Response.Write("< /TABLE >")
　End If

　　通过使用GetRows 指令，就可以获取整个记录集并将其装载到数组中。当恢复特别大的
记录集时，这种方法有可能会造成资源问题，但是数据的循环快多了，因为类似于MoveNext
 的函数调用和EOF 的检测都可以取消了。

　　不过速度的提升确实是有代价的，因为记录集的元数据不再与数据在一起。围绕这个问
题，我在调用GetRows之前用记录集来恢复标题名。另外还可以提前提取数据类型和其它信息
。还要注意，在我们的测试中，性能上的优势只有在使用大一些的记录集时才能看到。

　　在这部分最后的测试中，我们更进一步，使用记录集的GetString 指令。这个方法将整
个记录集提取到一个大的字符串中，允许你指定自己的分隔符( ADO__13.asp ):

　If objRS.EOF Then
　　Response.Write("No Records Found")
　　objRS.Close
　　Set objRS = Nothing
　Else
　　'write headings
　　...
　　'set array
　　Dim strTable
　　strTable = objRS.GetString (2, , "< /TD >< TD >", "< /TD >< /TR >< TR >< TD
>")
　　'close recordset early
　　objRS.Close
　　Set objRS = Nothing
　　Response.Write(strTable & "< /TD >< /TR >< /TABLE >")
　End If

　　虽然这种方法已经接近了最高水平，但是它只适合于最简单的设计，因为它根本就不能
应用于数据的特殊情况。

观察
　　在我们开始这套测试之前，执行每条记录的时间一直在.83 毫秒左右震动。这套测试中
的大多数方法都将这个数字减少了一半。虽然有些方法明显地提供了更快的速度，但是代价
是灵活性的降低。

　　下面的规则是以重要程度为顺序的：

* 当记录集中的值不需要用一种特殊方式来对待并且能够格式化为一种统一的格式时，使用
GetString方法来提取数据。
* 当你在设计上需要更大的灵活性，但是又不需要用记录集的元数据进行工作，使用GetRow
s 方法将数据提取到一个数组中。
* 当你需要设计的灵活性和元数据时，在进入一个数据恢复的循环之前，将你的域约束在本
地变量中。避免用名字引用域。

使用临时字符串可以较好地代替缓冲器吗？
　　这是针对我上一篇文章提交的一些注解所引发的一个小小的离题。要讨论的问题是围绕
着缓冲器的使用及使用临时字符串作为替代来收集输出，这样就允许Response.Write 只调用
一次。为了测试，我从ADO_11.asp的代码开始，将结果附加到一个字符串中，而不是在每个
循环都调用Response.Write，当整个操作都结束后，在字符串上调用Response.Write ( STR
__01.asp ):

　　Dim strTable
　　strTable = ""
　　'write headings
　　strTable = strTable & "< TABLE BORDER=1 >< TR >"
　　For i = 0 to fldCount-1
　　strTable = strTable & "< TH >" & fld(i).name & "< /TH >"
　　Next
　　strTable = strTable & "< /TR >"
　　'write data
　　Do While Not objRS.EOF
　　strTable = strTable & "< TR >"
　　For i = 0 to fldCount-1
　　strTable = strTable & "< TD >" & fld(i) & "< /TD >"
　　Next
　　strTable = strTable & "< /TR >"
　　objRS.MoveNext
　　Loop
　　For i = 0 to fldCount-1
　　Set fld(i) = Nothing
　　Next
　　strTable = strTable & "< /TABLE >"
　　Response.Write(strTable)

　　看起来执行得不是很好。也许正象许多人建议的，我们应该用Space 指令为这个字符串
指定一些空间，这样它就不需要在循环期间总是为自己重新分配空间( STR__02.asp ):

　　Dim strTable
　　strTable = Space(10000)

　　也许Space 指令并不象建议的那样工作。我们最后的规则是：不要用临时字符串来收集
输出。
       

 

 

规则的总结

　　现在我们来重新总结一下这些规则：

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

　　* 当使用一个单个记录集时，将连接字符串传递到ActiveConnection属性中。

　　* 在一个页面上使用多个记录集时，创建一个Connection 对象，在ActiveConnection
属性中重复使用它。

　　* 使用最适合你的任务的最简单的指针和锁的类型。

　　* 通过ADODB.Recordset 类例示记录集以获得最好的性能和最大的灵活性。

　　* 除非是一个断开的环境中所要求的，避免使用断开的记录集。

　　* 不要对单独设置记录集属性感到担心。

　　* 当记录集中的值不需要用一种特殊方式来对待并且能够格式化为一种统一的格式时，
使用GetString方法来提取数据。

　　* 当你在设计上需要更大的灵活性，但是又不需要用记录集的元数据进行工作，使用Ge
tRows方法将数据提取到一个数组中。

　　* 当你需要设计的灵活性和元数据时，在进入一个数据恢复的循环之前，将你的域约束
在本地变量中。避免用名字引用域。

　　* 不要用临时字符串来收集输出。

结论
　　同样，从这些测试中我们所学到的最重要的一点是：小小的变化会在性能上造成很大的
影响。如果我们把第一个测试与ADO__09.asp（在记录集中循环的最快结果）相比，可以看到
在反应时间上至少减少了50%。

　　如果我们把第一个测试与所有测试中最快的情况，即使用GetString 的方法相比较，就
会发现反应时间只是原始值的很小一部分。

　　所以要记住，永远不要想当然。如果你不能肯定，那就运行一些有针对性的测试。

本文相关资料：http://www.asptoday.com/articles/images/20000426.zip。