在服务器上生成动态内容是使用ASP最主要的原因之一，所以我们选择的第一个测试项目是确定把动态内容发送到应答流使用什么方法最好。基本的选择有两种（以及它们的一些变化）：使用内嵌ASP标记，使用Response.Write语句。

　　 为测试这些不同的方法，我们创建了一个简单的ASP页面，页面先定义一些变量然后把它们插入到表格。虽然这个页面很简单，而且没有实际用途，但它足以让我们分离和测试各个问题。

　　 2.1 使用ASP内嵌标记

　　 第一个测试是使用ASP的内嵌标记%= x %>，其中x是一个变量。这是使用最方便的方法，而且它可以让页面的HTML部分变得更容易阅读和维护。

/app1/response1.asp的完整代码

最好记录 = 8.28 毫秒/页




　　 2.2 使用Response.Write输出每一行HTML代码

　　 许多优秀的文献指出，应当避免使用前面的内嵌标记方法，因为它导致一个称为“上下文切换”的操作。这个操作发生在Web服务器所处理的代码类型发生变化的时候（从纯HTML的发送到脚本处理，或反过来），这种切换需要一定的时间。许多程序员在了解了这一点之后，他们的第一个反应是将每一行HTML代码都用Response.Write函数来输出：

/app1/response2.asp片断

最好记录 = 8.28 毫秒/页
响应时间 = 8.08 毫秒/页
差　　额 = -0.20 毫秒 （减少 2.4%）




　　 和内嵌标记版本相比，我们所看到的性能改善非常小，简直令人惊讶。这或许是因为页面中多出了许多函数调用。不过这种方法还有一个更大的缺点，由于HTML代码嵌入到了函数内，脚本代码变得非常冗长，阅读和维护都不方便。

　　 2.3 使用封装函数

　　 Response.Write并不会在文本行的末尾加上CRLF（Carriage Return - Line Feed，回车换行），这是使用上面这种方法最令人失望的地方。尽管已经在服务器端把HTML代码作了很好的格式化，但在浏览器中看到的仍旧只有长长的一行代码。不过失望的不仅是这一个问题，人们很快就发现不存在能够自动添加CRLF的Response.WriteLn函数。一个很自然的反应就是创建Response.Write的封装函数，在每行的后面加上CRLF：
...
writeCR("tr>td>b>First Name:/b>/td>td>" FirstName "/td>/tr>")
...
SUB writeCR(str)
Response.Write(str vbCRLF)
END SUB
/app1/response4.asp片断

最好记录 = 8.08 毫秒/页
响应时间 = 10.11 毫秒/页
差　　额 = +2.03 毫秒 （增加 25.1%）




　　 结果是性能的大大下降。当然，这主要是因为这种方法使得函数的调用次数加倍，它对性能的影响非常明显。应当不惜代价地避免这种用法，CRLF导致每行的末尾多了两个字节，而这两个字节对于浏览器显示页面是没有用的。在大多数情况下，浏览器端HTML代码的格式美观只是方便了你的竞争者阅读和理解页面的设计。

　　 2.4 合并多个Response.Write

　　 如果不考虑最后一次有关封装函数的测试，下一个合理的步骤应当是将所有字符串从分开的Response.Write语句合并到一个语句，从而减少函数调用次数、提高代码运行效率。

/app1/response3.asp片断

最好记录 = 8.08 毫秒/页
响应时间 = 7.05 毫秒/页
差　　额 = -1.03 毫秒 （减少 12.7%）




　　 这是目前为止最好的方法。

　　 2.5 合并多个Response.Write，且在每一行的末尾增加CRLF

　　 也有人非常关注他们的HTML代码在浏览器端是否美观，因此我们又在每一行HTML代码的末尾加上了一个回车，使用的是vbCRLF常量，其他的测试代码与上例一样。
...
Response.Write("html>" vbCRLF _
"head>" vbCRLF _
" title>Response Test/title>" vbCRLF _
"/head>" vbCRLF _
...
/app1/response5.asp片断

最好记录 = 7.05 毫秒/页
响应时间 = 7.63 毫秒/页
差　　额 = +0.58 毫秒 （增加 8.5%）




　　 结果是性能略有下降，这可能是因为增加了字符串连接操作，同时输出的文本也增加了。

　　 2.6 意见

　　 根据上述ASP输出测试的结果，我们得出如下编码规则：

避免过多地使用内嵌ASP。
把尽可能多的Response.Write语句合并成单个语句。
绝对不要为了加上CRLF而封装Response.Write。
如果要格式化HTML输出，直接在Response.Write语句后面加上CRLF。

纲要：ASP动态生成的内容以什么方式输出效率最高？最好用哪种方法提取数据库记录集？本文测试了近20个这类ASP开发中常见的问题，测试工具所显示的时间告诉我们：这些通常可以想当然的问题不仅值得关注，而且还有出乎意料的秘密隐藏在内。

一、测试目的

　　 本文的第一部分考察了ASP开发中的一些基本问题，给出了一些性能测试结果以帮助读者理解放入页面的代码到底对性能有什么影响。ADO是由Microsoft开发的一个通用、易用的数据库接口，事实证明通过ADO与数据库交互是ASP最重要的应用之一，在第二部分中，我们就来研究这个问题。

　　 ADO所提供的功能相当广泛，因此准备本文最大的困难在于如何界定问题的范围。考虑到提取大量的数据可能显著地增加Web服务器的负载，所以我们决定这一部分的主要目的是找出什么才是操作ADO记录集的最优配置。然而，即使缩小了问题的范围，我们仍旧面临很大的困难，因为ADO可以有许多种不同的方法来完成同一个任务。例如，记录集不仅可以通过Recordset类提取，而且也可以通过Connection和Command类提取；即使得到记录集对象之后，还有许多可能戏剧性地影响性能的操作方法。然而，与第一部分一样，我们将尽可能地涵盖最广泛的问题。

　　 具体地讲，这一部分的目标是收集足够多的信息，回答下列问题：

l是否应该通过包含引用ADOVBS.inc？
l使用记录集时是否应该创建单独的连接对象？
l最好用哪种方法提取记录集？
l哪种游标类型和记录锁定方式效率最高？
l是否应该使用本地记录集？
l设置记录集属性用哪种方法最好？
l用哪种方法引用记录集字段值效率最高？
l用临时字符串收集输出是一种好方法吗？

二、测试环境

　　 本测试总共用到了21个ASP文件，这些文件可以从本文后面下载。每一个页面设置成可以运行三种不同的查询，分别返回0、25、250个记录。这将帮助我们隔离页面本身的初始化、运行开销与用循环访问记录集的开销。

　　 为便于测试，数据库连接字符串和SQL命令串都在Global.asa中作为Application变量保存。由于我们的测试数据库是SQL Server 7.0，因此连接串指定OLEDB作为连接提供者，测试数据来自SQL Server的Northwind数据库。SQL SELECT命令从NorthWind Orders表提取7个指定的字段。

　　 测试服务器配置如下：450 Mhz Pentium，512 MB RAM，NT Server 4.0 SP5，MDAC 2.1（数据访问组件），以及5.0版本的Microsoft脚本引擎。SQL Server运行在另外一台具有类似配置的机器上。和第一部分一样，我们仍旧使用Microsoft Web Application Stress Tool 记录从第一个页面请求到从服务器接收到最后一个字节的时间（TTLB，Time To Last Byte），时间以毫秒为单位。测试脚本调用每个页面1300次以上，运行时间约20小时，以下显示的时间是会话的平均TTLB。请记住，和第一部分一样，我们只关心代码的效率，而不是它的可伸缩性或服务器性能。

　　 同时请注意我们启用了服务器的缓冲。另外，为了让所有的文件名字长度相同，有的文件名字中嵌入了一个或多个下划线。
三、第一次测试

　　 在第一次测试中，我们模拟Microsoft ASP ADO示例中可找到的典型情形提取一个记录集。在这个例子（ADO__01.asp）中，我们首先打开一个连接，然后创建记录集对象。当然，这里的脚本按照本文第一部分所总结的编码规则作了优化。

　　 下面是测试结果：

　　 我们来看一下各栏数字的含义：
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" -->

　　 因此，我们的第一条规则为：

l避免包含ADOVBS.inc文件，通过其他方法访问和使用ADO常量。
五、使用记录集时是否应该创建单独的连接对象？

　　 要正确地回答这个问题，我们必须分析两种不同条件下的测试：第一，页面只有一个数据库事务；第二，页面有多个数据库事务。

　　 在前例中，我们创建了一个单独的Connection对象并将它赋给Recordset的ActiveConnection属性。然而，如ADO__03.asp所示，我们也可以直接把连接串赋给ActiveConnection属性，在脚本中初始化和配置Connection对象这一额外的步骤可以省去。

objRS.ActiveConnection = Application("Conn")

　　 虽然Recordset对象仍旧要创建一个连接，但此时的创建是在高度优化的条件下进行的。因此，与上一次测试相比，页面开销又下降了23%，而且如预期的一样，单个记录的显示时间没有实质的变化。

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

l如果只使用一个记录集，直接把连接串赋给ActiveConnection属性。

　　 接下来我们检查页面用到多个记录集时，上述规则是否仍旧有效。为测试这种情形，我们引入一个FOR循环将前例重复10次。在这个测试中，我们将研究三种变化：

　　 第一，如ADO__04.asp所示，在每一个循环中建立和拆除Connection对象：

　　 第二，如ADO__05.asp所示，在循环外面创建Connection对象，所有记录集共享该对象：

　　 第三，如ADO__06.asp所示，在每一个循环内把连接串赋给ActiveConnection属性：


　　 就象我们可以猜想到的一样，在循环内创建和拆除连接对象是效率最差的方法。不过，令人惊异的是，在循环内直接把连接串赋给ActiveConnection属性只比共享单个连接对象稍微慢了一点。

　　 尽管如此，第三规则应该为：

l同一页面内用到多个记录集时，创建单一的连接对象并通过ActiveConnection属性共享它。
六、哪种游标类型和记录锁定方式效率最高？

　　 迄今为止的所有测试中我们只使用了“只能向前”的游标来访问记录集。ADO为记录集提供的游标还有三种类型：静态可滚动的游标，动态可滚动的游标，键集游标。每种游标都提供不同的功能，比如访问前一记录和后一记录、是否可以看到其他程序对数据的修改等。不过，具体讨论每一种游标类型的功用已经超出了本文的范围，下表是各种游标类型的一个比较性的分析。

　　 和“只能向前”类型的游标相比，所有其它的游标类型都需要额外的开销，而且这些游标在循环内一般也要慢一些。因此，我们愿与您共享如下告诫：永远不要这样认为——“唔，有时候我会用到动态游标，那么我就一直使用这种游标吧。”

　　 同样的看法也适用于记录锁定方式的选择。前面的测试只用到了只读的加锁方式，但还存在其他三种方式：保守式、开放式、开放式批处理方式。和游标类型一样，这些锁定方式为处理记录集数据提供了不同的功能和控制能力。

　　 我们得出如下规则：

l使用适合于处理任务的最简单的游标类型和记录锁定方式。
七、最好用哪种方法提取记录集？

　　 到目前为止我们一直通过创建Recordset对象提取记录集，但是ADO也提供了间接的记录集提取方法。下面的测试比较ADO__03.asp和直接从Connection对象创建记录集（CONN_01.asp）这两种方法：

　　 可以看到页面开销略有增加，单个记录的显示时间没有变化。

　　 下面我们再来看看从Command对象直接创建记录集对象（CMD__02.asp）：

　　 同样，页面开销也略有增加，而单个记录的显示时间没有本质的变化。后面这两种方法在性能上的差异很小，但我们还有一个重要的问题需要考虑。

　　 通过Recordset类创建记录集时，我们能够以最大的灵活性控制记录集的处理方式。既然后面两种方法未能有压倒性的性能表现，我们主要还是考虑默认返回的游标类型和记录锁定方式，对于某些场合来说默认值并不一定是最理想的。

　　 因此，除非由于特殊的原因需要选择后面两种方法，否则我们建议考虑下面的规则：

l通过ADODB.Recordset类实例化记录集，以获得最好的性能和灵活性。

八、是否应该使用本地记录集？

　　 ADO允许使用本地（客户端）记录集，此时查询将提取记录集内的所有数据，查询完成后连接可以立即关闭，以后使用本地的游标访问数据，这为释放连接带来了方便。使用本地记录集对于访问那些要求数据离线使用的远程数据服务非常重要，那么，对于普通的应用它是否同样有所帮助？

　　 下面我们加入CursorLocation属性，并在打开记录集之后关闭了连接（CLIENT1.asp）：

　　 理论上，这种方法由于以下两个原因会对效率有所好处：第一，它避免了在记录之间移动时重复地通过连接请求数据；第二，由于能够方便地释放连接，它减轻了资源需求。然而，从上表看起来使用本地记录集对提高效率显然没有什么帮助。这或许是因为使用本地记录集时，不管程序设置的是什么，游标总是变成静态类型。

　　 第6个规则如下：

l除非确实要求记录集本地化，否则应避免使用。
十、用哪种方法引用记录集字段值效率最高？

　　 10.1 测试

　　 至此为止我们一直通过名字引用记录集中的字段值。由于这种方法要求每次都必须寻找相应的字段，它的效率并不高。为证明这一点，下面这个测试中我们通过字段在集合中的索引引用它的值（ADO__08.asp）：


　　 和预期的一样，页面开销也有小小的变化（这或许是因为代码略有减少）。然而，这种方法在显示时间上的改善是相当明显的。

　　 在下一个测试中，我们把所有的字段分别绑定到变量（ADO__09.asp）：

　　 这是目前为止最好的记录。请注意单个记录的显示时间已经降低到0.45毫秒以下。

　　 上述脚本都要求对结果记录集的构造有所了解。例如，我们在列标题中直接使用了字段名字，单独地引用各个字段值。下面这个测试中，不仅字段数据通过遍历字段集合得到，而且字段标题也用同样的方式得到，这是一种更为动态的方案（ADO__10.asp）。

　　 可以看到，代码性能有所下降，但它仍旧要比ADO__07.asp要快。

　　 下一个测试示例是前面两个方法的折衷。我们将继续保持动态特征，同时通过在动态分配的数组中保存字段引用提高性能：


　　 虽然还不能超过以前最好的成绩，但它比开头的几个示例要快，同时它具有动态地处理任何记录集这一优点。

　　 与前面的测试代码相比，下面的测试代码有了根本性的改动。它使用记录集对象的GetRows方法填充数组以供循环访问数据，而不是直接访问记录集本身。注意在调用GetRows之后立即把Recordset设置成了Nothing，也就是尽快地释放了系统资源。另外，请注意数组的第一维代表字段，第二维代表行（ADO__12.asp）。

　　 使用GetRows方法时，整个记录集都被提取到了数组。虽然记录集极端庞大时可能产生资源问题，但是用循环访问数据的速度确实更快了，这是由于取消了MoveNext和检查EOF之类的函数调用。

　　 速度是要付出代价的，现在记录集的元数据已经丢失了。为解决这个问题，我们可以在调用GetRows之前从记录集对象提取标题信息；此外，数据类型和其他信息也可以预先提取。另外还要注意的是，测试中性能上的优势只有在记录集较大的时候才会出现。

　　 这一组的最后一个测试中，我们使用了记录集的GetString方法。GetString方法将整个记录集提取成为一个大的字符串，并允许指定分隔符（ADO__13.asp）：