本文的第一部分考察了ASP开发中的一些基本问题，给出了一些性能测试结果以帮助读者理解放入页面的代码到底对性能有什么影响。ADO是由Microsoft开发的一个通用、易用的数据库接口，事明通过ADO与数据库交互是ASP最重要的应用之一，在第二部分中，我们就来研究这个问题。
ADO所提供的功能相当广泛，因此准备本文最大的困难在于如何界定问题的范围。考虑到提取大量的数据可能显著地增加Web服务器的负载，所以我们决定这一部分的主要目的是找出什么才是操作ADO记录集的最优配置。然而，即使缩小了问题的范围，我们仍旧面临很大的困难，因为ADO可以有许多种不同的方法来完成同一个任务。例如，记录集不仅可以通过Recordset类提取，而且也可以通过Connection和Command类提取；即使得到记录集对象之后，还有许多可能戏剧性地影响性能的操作方法。然而，与第一部分一样，我们将尽可能地涵盖最广泛的问题。
本测试总共用到了21个ASP文件，这些文件可以从本文后面下载。每一个页面设置成可以运行三种不同的查询，分别返回0、25、250个记录。这将帮助我们隔离页面本身的初始化、运行开销与用循环访问记录集的开销。
测试服务器配置如下：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（毫秒）。在所有的测试中，该值被视为生成页面本身（包括创建对象）的时间开销，不包含循环访问记录集数据的时间。
disp time/2525栏的TTLB减去0栏的TTLB，然后除以25。该值反映了在循环记录集时显示单个记录所需时间。
disp time/250250栏的TTLB减去0栏的TTLB，再除以250。该值反映了在循环记录集时显示单个记录所需时间。
Microsoft提供的ADOVBS.inc包含了270行代码，这些代码定义了大多数的ADO属性常量。我们这个示例只从ADOVBS.inc引用了2个常量。因此本次测试（ADO__02.asp）中我们删除了包含文件引用，设置属性时直接使用相应的数值。
可以看到页面开销下降了23%。该值并不影响单个记录的提取和显示时间，因为这里的变化不会影响循环内的记录集操作。有多种方法可以解决ADOVBS.inc的引用问题。我们将ADOVBS.inc文件作为参考，设置时通过注释加以说明。请记住，正如第一部分所指出的，适度地运用注释对代码的效率影响极小。另外一种方法是将那些需要用到的常量从ADOVBS.inc文件拷贝到页面内。
还有一个解决该问题的好方法，这就是通过链接ADO类型库使得所有的ADO常量直接可用。把下面的代码加入Global.asa文件，即可直接访问所有的ADO常量：
要正确地回答这个问题，我们必须分析两种不同条件下的测试：第一，页面只有一个数据库事务；第二，页面有多个数据库事务。
在前例中，我们创建了一个单独的Connection对象并将它赋给Recordset的ActiveConnection属性。然而，如ADO__03.asp所示，我们也可以直接把连接串赋给ActiveConnection属性，在脚本中初始化和配置Connection对象这一额外的步骤可以省去。
虽然Recordset对象仍旧要创建一个连接，但此时的创建是在高度优化的条件下进行的。因此，与上一次测试相比，页面开销又下降了23%，而且如预期的一样，单个记录的显示时间没有实质的变化。
接下来我们检查页面用到多个记录集时，上述规则是否仍旧有效。为测试这种情形，我们引入一个FOR循环将前例重复10次。在这个测试中，我们将研究三种变化：
第二，如ADO__05.asp所示，在循环外面创建Connection对象，所有记录集共享该对象：
就象我们可以猜想到的一样，在循环内创建和拆除连接对象是效率最差的方法。不过，令人惊异的是，在循环内直接把连接串赋给ActiveConnection属性只比共享单个连接对象稍微慢了一点。
l同一页面内用到多个记录集时，创建单一的连接对象并通过ActiveConnection属性共享它。
迄今为止的所有测试中我们只使用了“只能向前”的游标来访问记录集。ADO为记录集提供的游标还有三种类型：静态可滚动的游标，动态可滚动的游标，键集游标。每种游标都提供不同的功能，比如访问前一记录和后一记录、是否可以看到其他程序对数据的修改等。不过，具体讨论每一种游标类型的功用已经超出了本文的范围，下表是各种游标类型的一个比较性的分析。
和“只能向前”类型的游标相比，所有其它的游标类型都需要额外的开销，而且这些游标在循环内一般也要慢一些。因此，我们愿与您共享如下：永远不要这样认为——“唔，有时候我会用到动态游标，那么我就一直使用这种游标吧。”
同样的看法也适用于记录锁定方式的选择。前面的测试只用到了只读的加锁方式，但还存在其他三种方式：保守式、式、式批处理方式。和游标类型一样，这些锁定方式为处理记录集数据提供了不同的功能和控制能力。
到目前为止我们一直通过创建Recordset对象提取记录集，但是ADO也提供了间接的记录集提取方法。下面的测试比较ADO__03.asp和直接从Connection对象创建记录集（CONN_01.asp）这两种方法：
同样，页面开销也略有增加，而单个记录的显示时间没有本质的变化。后面这两种方法在性能上的差异很小，但我们还有一个重要的问题需要考虑。
通过Recordset类创建记录集时，我们能够以最大的灵活性控制记录集的处理方式。既然后面两种方法未能有压倒性的性能表现，我们主要还是考虑默认返回的游标类型和记录锁定方式，对于某些场合来说默认值并不一定是最理想的。
ADO允许使用本地（客户端）记录集，此时查询将提取记录集内的所有数据，查询完成后连接可以立即关闭，以后使用本地的游标访问数据，这为连接带来了方便。使用本地记录集对于访问那些要求数据离线使用的远程数据服务非常重要，那么，对于普通的应用它是否同样有所帮助？
下面我们加入CursorLocation属性，并在打开记录集之后关闭了连接（CLIENT1.asp）：
理论上，这种方法由于以下两个原因会对效率有所好处：第一，它避免了在记录之间移动时重复地通过连接请求数据；第二，由于能够方便地连接，它减轻了资源需求。然而，从上表看起来使用本地记录集对提高效率显然没有什么帮助。这或许是因为使用本地记录集时，不管程序设置的是什么，游标总是变成静态类型。
至此为止我们一直通过名字引用记录集中的字段值。由于这种方法要求每次都必须寻找相应的字段，它的效率并不高。为证明这一点，下面这个测试中我们通过字段在集合中的索引引用它的值（ADO__08.asp）：
和预期的一样，页面开销也有小小的变化（这或许是因为代码略有减少）。然而，这种方法在显示时间上的改善是相当明显的。
上述脚本都要求对结果记录集的构造有所了解。例如，我们在列标题中直接使用了字段名字，单独地引用各个字段值。下面这个测试中，不仅字段数据通过遍历字段集合得到，而且字段标题也用同样的方式得到，这是一种更为动态的方案（ADO__10.asp）。
下一个测试示例是前面两个方法的折衷。我们将继续保持动态特征，同时通过在动态分配的数组中保存字段引用提高性能：
虽然还不能超过以前最好的成绩，但它比开头的几个示例要快，同时它具有动态地处理任何记录集这一优点。
与前面的测试代码相比，下面的测试代码有了根本性的改动。它使用记录集对象的GetRows方法填充数组以供循环访问数据，而不是直接访问记录集本身。注意在调用GetRows之后立即把Recordset设置成了Nothing，也就是尽快地了系统资源。另外，请注意数组的第一维代表字段，第二维代表行（ADO__12.asp）。
使用GetRows方法时，整个记录集都被提取到了数组。虽然记录集极端庞大时可能产生资源问题，但是用循环访问数据的速度确实更快了，这是由于取消了MoveNext和检查EOF之类的函数调用。
速度是要付出代价的，现在记录集的元数据已经丢失了。为解决这个问题，我们可以在调用GetRows之前从记录集对象提取标题信息；此外，数据类型和其他信息也可以预先提取。另外还要注意的是，测试中性能上的优势只有在记录集较大的时候才会出现。
这一组的最后一个测试中，我们使用了记录集的GetString方法。GetString方法将整个记录集提取成为一个大的字符串，并允许指定分隔符（ADO__13.asp）：
虽然这种方法在速度上的好处非常明显，但它只适用于最简单的操作，根本无法适应稍微复杂的数据操作要求。
推荐：
网友评论 ()条 查看