ASP(Active Server Page)是Microsoft公司推出的基于PWS(Personal Web Server)&IIS(Internet Information Server)平台的、基于ISAPI(InternetServiceAPI)原理的动态网页开发技术，目前日趋成熟完善。在这里仅就代码优化进行一些简单讨论。
1、声明VBScript变量
在ASP中，对vbscript提供了强劲的支持，能够无缝集成vbscript的函数、方法，这样给扩展ASP的现有功能提供了很大便利。由于ASP中已经模糊了变量类型的概念，所以，在进行ASP与vbscript交互的过程中，很多程序员也惯于不声明vbscript的变量，这样加重了服务器的解析负担，进而影响服务器的响应请求速度。
鉴于此，我们可以象在VB中强制用户进行变量声明一样在vbscript中强制用户进行变量声明。实现方法是在ASP程序行首放置＜% option explicit%＞。
2、对URL地址进行编码
在我们使用asp动态生成一个带参数URL地址并进行跳转时，在IE中解析很正常，但在NetScrape浏览时却有错误如下：
HTTP Error 400
400 Bad Request
Due to malformed syntax, the request could not be understood by the server.
The client should not repeat the request without modifications.
解决方法是对生成的URL参数使用ASP内置server对象的URLencode方法进行URL编码，例子如下：
＜%
URL="xur.asp"
var1="username=" & server.URLencode("xur")
var2="&company=" & server.URLencode("xurstudio")
var3="&phone=" & server.URLencode("021-53854336-186")
response.redirect URL & "?" & var1 & var2 & var3
%＞
3、清空对象
当使用完对象后，首先使用Close方法来释放对象所占用的系统资源；然后设置对象值为“nothing”释放对象占用内存。当年，我就是在一张页面上创建了百余个没有清空对象的记录集而崩溃了我的IIS 。下面的代码使用数据库内容建立一个下拉列表。代码示例如下：
＜% myDSN="DSN=xur;uid=xur;pwd=xur"
mySQL="select * from authors where AU_ID＜100"
set conntemp=server.createobject("adodb.connection")
conntemp.open myDSN
set rstemp=conntemp.execute(mySQL)
if rstemp.eof then
response.write "数据库为空"
response.write mySQL
conntemp.close
set conntemp=nothing
response.end
end if%＞
＜%do until rstemp.eof %＞
＜%
rstemp.movenext
loop
rstemp.close
set rstemp=nothing
conntemp.close
set conntemp=nothing
%＞
4、使用字符串建立SQL查询
使用字符串来建立查询并不能加快服务器的解析速度，相反，它还会增加服务器的解析时间。但在这里仍然推荐使用字符串代替简单的查询语句来进行查询。这样做的好处是，可以迅速发现程序问题所在，从而便利高效地生成程序。示例如下：
＜%mySQL= ""select * "
mySQL= mySQL & "from publishers"
mySQL= mySQL & "where state='NY'"
response.write mySQL
set rstemp=conntemp.execute(mySQL)
rstemp.close
set rstemp=nothing
%＞
5、使用case进行条件选择
在进行条件选择的时候，尽量使用case语句，避免使用if语句。使用case语句，可以使程序流程化，执行起来也比if语句来的快。示例如下：
＜%
FOR i = 1 TO 1000
n = i
Response.Write AddSuffix(n) & "＜br＞"
NEXT
%＞
＜%
Function AddSuffix(num)
numpart = RIGHT(num,1)
SELECT CASE numpart
CASE "1"
IF InStr(num,"11") THEN
num = num & "th"
ELSE
num = num & "st"
END IF
CASE "2"
IF InStr(num,"12") THEN
num = num & "th"
ELSE
num = num & "nd"
END IF
CASE "3"
IF InStr(num,"13") THEN
num = num & "th"
ELSE
num = num & "rd"
END IF
CASE "4"
num = num & "th"
CASE ELSE
num = num & "th"
END SELECT
AddSuffix = num
END FUNCTION
%＞
6、使用adovbs.inc文件中定义的常量打开记录集
打开记录集时，可以定义记录集打开的游标类型和锁定类型。在adovbs.inc文件中定义了一些常量来定义这些类型。adovbs.inc文件保存在\inetpub\iissamples\IISamples目录下面。下面列举几个常用的游标类型和锁定类型。
游标类型：adOpenFowardOnly游标只能向前；adOpenKeyset游标可向前或者向后，如一用户添加记录，新记录不会出现在记录集中；adOpenDynamic游标动态随意；adOpenStatic记录集不对其他用户造成的记录修改有所反映。
锁定类型：adLockReadOney不能修改记录集中的记录；adLockPessimistic在编辑一条记录时锁定它；adLockOptimstic调用记录集Update方法时才锁定记录；adLockBatchOpeimstic记录只能成批更新。
＜!--#INCLUDE VIRTUAL="/ADOVBS.INC" --＞
＜%
connectme="DSN=xur;uid=xur;pwd=xur"
sqltemp="select * from publishers where name='xur'"
set rstemp=Server.CreateObject("adodb.Recordset")
rstemp.open sqltemp, connectme, adOpenStatic，adLockOptimstic
response.write rstemp.recordcount & " records in＜br＞" & sqltemp
rstemp.close
set rstemp=nothing
%＞
7、避免在使用global.asa文件中进行对象定义
由于global.asa文件中的内容可以为站点内所有文件引用，无疑，在global.asa文件中进行对象定义可以省去很多重复工作。比如在global.asa中的application_onstart函数中进行如下定义：
＜%SUB application_onstart
set application("theCONN")=server.createobject("adodb.connection")
END SUB %＞;
这样就可以在站点任何代码中做类似引用：
＜%
mySQL="select * from publishers where state='xur'
set rstemp=application("theconn").execute(mySQL)
%＞
同样地，可以在session_onstart函数中创建记录集对象
＜%SUB session_onstart
set session("rstemp")=server.createobject("adodb.recordset")
END SUB %＞
然后在站点也面中进行如下引用：
＜%
mySQL="select * from publishers where state='xur'
set session("rstemp")=conntemp.execute(mySQL)
%＞
但这样做的同时也有很大的负面影响，由于Application和session变量都只有在关闭网站的时候才释放占用的资源，所以session参数会浪费大量不必要内存，而且此时application变量成为服务器性能的瓶颈。
解决方法：建立定义对象asp页面，在需要进行调用这些对象的页面上，引入这张asp页面。假设定义对象的asp页面名称为define.asp，则只要在对应asp页面中加入以下语句就能引入该页面。
＜!--#INCLUDE VIRTUAL="/define.asp" --＞
在进行页面引进时，最好在待引进的asp文件中不要包含＜%@LANGUAGE="VBSCRIPT"%＞语句。因为在asp文件中，只能有一句由@来定义的脚本解析语言。
8、安全防护
asp提供了很好的代码保护机制，所有的asp代码都在服务器端执行而只返回给客户端代码执行结果。即便这样，在老版本的IIS中还可以在文件名后面家::$DATA来查看asp的源代码，这已经属于Web Server安全范畴不在本文讨论范围内。下面提出两点简单的安全注意事项。
虽然在asp中建议引入文件以inc作为扩展名，在这里仍建议以asp作为引文件的扩展名。当这些代码在安全机制不好的Web Server上运行时，只需在地址栏上输入引入文件的地址(inc为扩展名)，就可以浏览该引入文件的内容，这是由于在Web Server上，如果没有定义好解析某类型（比如inc）的动态连接库时，该文件以源码方式显示。
不要把数据库文件放在网站结构内部，这样，当恶意人士获取数据库路径后，就可以轻易获取该数据库，进而肆意更改数据库内容。比较好的做法是，为数据库建立DSN（Date Source Name），而在进行数据库访问时直接访问该DSN。
1、声明VBScript变量
在ASP中，对vbscript提供了强劲的支持，能够无缝集成vbscript的函数、方法，这样给扩展ASP的现有功能提供了很大便利。由于ASP中已经模糊了变量类型的概念，所以，在进行ASP与vbscript交互的过程中，很多程序员也惯于不声明vbscript的变量，这样加重了服务器的解析负担，进而影响服务器的响应请求速度。
鉴于此，我们可以象在VB中强制用户进行变量声明一样在vbscript中强制用户进行变量声明。实现方法是在ASP程序行首放置＜% option explicit%＞。
2、对URL地址进行编码
在我们使用asp动态生成一个带参数URL地址并进行跳转时，在IE中解析很正常，但在NetScrape浏览时却有错误如下：
HTTP Error 400
400 Bad Request
Due to malformed syntax, the request could not be understood by the server.
The client should not repeat the request without modifications.
解决方法是对生成的URL参数使用ASP内置server对象的URLencode方法进行URL编码，例子如下：
＜%
URL="xur.asp"
var1="username=" & server.URLencode("xur")
var2="&company=" & server.URLencode("xurstudio")
var3="&phone=" & server.URLencode("021-53854336-186")
response.redirect URL & "?" & var1 & var2 & var3
%＞
3、清空对象
当使用完对象后，首先使用Close方法来释放对象所占用的系统资源；然后设置对象值为“nothing”释放对象占用内存。当年，我就是在一张页面上创建了百余个没有清空对象的记录集而崩溃了我的IIS 。下面的代码使用数据库内容建立一个下拉列表。代码示例如下：
＜% myDSN="DSN=xur;uid=xur;pwd=xur"
mySQL="select * from authors where AU_ID＜100"
set conntemp=server.createobject("adodb.connection")
conntemp.open myDSN
set rstemp=conntemp.execute(mySQL)
if rstemp.eof then
response.write "数据库为空"
response.write mySQL
conntemp.close
set conntemp=nothing
response.end
end if%＞
＜%do until rstemp.eof %＞
＜%
rstemp.movenext
loop
rstemp.close
set rstemp=nothing
conntemp.close
set conntemp=nothing
%＞
4、使用字符串建立SQL查询
使用字符串来建立查询并不能加快服务器的解析速度，相反，它还会增加服务器的解析时间。但在这里仍然推荐使用字符串代替简单的查询语句来进行查询。这样做的好处是，可以迅速发现程序问题所在，从而便利高效地生成程序。示例如下：
＜%mySQL= ""select * "
mySQL= mySQL & "from publishers"
mySQL= mySQL & "where state='NY'"
response.write mySQL
set rstemp=conntemp.execute(mySQL)
rstemp.close
set rstemp=nothing
%＞
5、使用case进行条件选择
在进行条件选择的时候，尽量使用case语句，避免使用if语句。使用case语句，可以使程序流程化，执行起来也比if语句来的快。示例如下：
＜%
FOR i = 1 TO 1000
n = i
Response.Write AddSuffix(n) & "＜br＞"
NEXT
%＞
＜%
Function AddSuffix(num)
numpart = RIGHT(num,1)
SELECT CASE numpart
CASE "1"
IF InStr(num,"11") THEN
num = num & "th"
ELSE
num = num & "st"
END IF
CASE "2"
IF InStr(num,"12") THEN
num = num & "th"
ELSE
num = num & "nd"
END IF
CASE "3"
IF InStr(num,"13") THEN
num = num & "th"
ELSE
num = num & "rd"
END IF
CASE "4"
num = num & "th"
CASE ELSE
num = num & "th"
END SELECT
AddSuffix = num
END FUNCTION
%＞
6、使用adovbs.inc文件中定义的常量打开记录集
打开记录集时，可以定义记录集打开的游标类型和锁定类型。在adovbs.inc文件中定义了一些常量来定义这些类型。adovbs.inc文件保存在\inetpub\iissamples\IISamples目录下面。下面列举几个常用的游标类型和锁定类型。
游标类型：adOpenFowardOnly游标只能向前；adOpenKeyset游标可向前或者向后，如一用户添加记录，新记录不会出现在记录集中；adOpenDynamic游标动态随意；adOpenStatic记录集不对其他用户造成的记录修改有所反映。
锁定类型：adLockReadOney不能修改记录集中的记录；adLockPessimistic在编辑一条记录时锁定它；adLockOptimstic调用记录集Update方法时才锁定记录；adLockBatchOpeimstic记录只能成批更新。
＜!--#INCLUDE VIRTUAL="/ADOVBS.INC" --＞
＜%
connectme="DSN=xur;uid=xur;pwd=xur"
sqltemp="select * from publishers where name='xur'"
set rstemp=Server.CreateObject("adodb.Recordset")
rstemp.open sqltemp, connectme, adOpenStatic，adLockOptimstic
response.write rstemp.recordcount & " records in＜br＞" & sqltemp
rstemp.close
set rstemp=nothing
%＞
7、避免在使用global.asa文件中进行对象定义
由于global.asa文件中的内容可以为站点内所有文件引用，无疑，在global.asa文件中进行对象定义可以省去很多重复工作。比如在global.asa中的application_onstart函数中进行如下定义：
＜%SUB application_onstart
set application("theCONN")=server.createobject("adodb.connection")
END SUB %＞;
这样就可以在站点任何代码中做类似引用：
＜%
mySQL="select * from publishers where state='xur'
set rstemp=application("theconn").execute(mySQL)
%＞
同样地，可以在session_onstart函数中创建记录集对象
＜%SUB session_onstart
set session("rstemp")=server.createobject("adodb.recordset")
END SUB %＞
然后在站点也面中进行如下引用：
＜%
mySQL="select * from publishers where state='xur'
set session("rstemp")=conntemp.execute(mySQL)
%＞
但这样做的同时也有很大的负面影响，由于Application和session变量都只有在关闭网站的时候才释放占用的资源，所以session参数会浪费大量不必要内存，而且此时application变量成为服务器性能的瓶颈。
解决方法：建立定义对象asp页面，在需要进行调用这些对象的页面上，引入这张asp页面。假设定义对象的asp页面名称为define.asp，则只要在对应asp页面中加入以下语句就能引入该页面。
＜!--#INCLUDE VIRTUAL="/define.asp" --＞
在进行页面引进时，最好在待引进的asp文件中不要包含＜%@LANGUAGE="VBSCRIPT"%＞语句。因为在asp文件中，只能有一句由@来定义的脚本解析语言。
8、安全防护
asp提供了很好的代码保护机制，所有的asp代码都在服务器端执行而只返回给客户端代码执行结果。即便这样，在老版本的IIS中还可以在文件名后面家::$DATA来查看asp的源代码，这已经属于Web Server安全范畴不在本文讨论范围内。下面提出两点简单的安全注意事项。
虽然在asp中建议引入文件以inc作为扩展名，在这里仍建议以asp作为引文件的扩展名。当这些代码在安全机制不好的Web Server上运行时，只需在地址栏上输入引入文件的地址(inc为扩展名)，就可以浏览该引入文件的内容，这是由于在Web Server上，如果没有定义好解析某类型（比如inc）的动态连接库时，该文件以源码方式显示。
不要把数据库文件放在网站结构内部，这样，当恶意人士获取数据库路径后，就可以轻易获取该数据库，进而肆意更改数据库内容。比较好的做法是，为数据库建立DSN（Date Source Name），而在进行数据库访问时直接访问该DSN。
第二课.改进 ASP 应用程序中的字符串处理性能
James Musson
Developer Services, Microsoft UK
2003年3月
适用于：
Microsoft? Active Server Pages?
Microsoft Visual Basic?摘要：大多数 Active Server Pages (ASP) 应用程序都要通过字符串连接来创建呈现给用户的 HTML 格式的数据。本文对几种创建此 HTML 数据流的方法进行了比较，在特定情况下，某些方法在性能方面要优于其他方法。本文假定您已经具备一定的 ASP 和 Visual Basic 编程方面的知识。
简介
编写 ASP 页面时，开发人员实际上是创建一个格式化的文本流，通过 ASP 提供的 Response 对象写入 Web 客户端。创建此文本流的方法有多种，而您选择的方法将对 Web 应用程序的性能和可缩放性产生很大影响。很多次，在我帮助客户优化其 Web 应用程序的性能时，发现其中一个比较有效的方法是更改 HTML 流的创建方式。本文将介绍几种常用技术，并测试它们对一个简单的 ASP 页面的性能所产生的影响。 ASP 设计
许多 ASP 开发人员都遵循良好的软件工程原则，尽可能地将其代码模块化。这种设计通常使用一些包含文件，这些文件中包含对页面的特定不连续部分进行格式化生成的函数。这些函数的字符串输出（通常是 HTML 表格代码）可以通过各种组合创建一个完整的页面。某些开发人员对此方法进行了改进，将这些 HTML 函数移到 Visual Basic COM 组件中，希望充分利用已编译的代码提供的额外性能。尽管这种设计方法很不错，但创建组成这些不连续 HTML 代码组件的字符串所使用的方法将对 Web 站点的性能和可缩放性产生很大的影响，无论实际的操作是在 ASP 包含文件中执行还是在 Visual Basic COM 组件中执行。字符串连接
请看以下 WriteHTML 函数的代码片断。名为 Data 的参数只是一个字符串数组，其中包含一些要格式化为表格结构的数据（例如，从数据库返回的数据）。
Function WriteHTML( Data )
Dim nRep For nRep = 0 to 99
sHTML = sHTML & vbcrlf _
& "" & (nRep + 1) & "" _
& Data( 0, nRep ) & "" _
& Data( 1, nRep ) & "" _
& Data( 2, nRep ) & "" _
& Data( 3, nRep ) & "" _
& Data( 4, nRep ) & "" _
& Data( 5, nRep ) & "" Next
WriteHTML = sHTML
End Function
这是很多 ASP 和 Visual Basic 开发人员创建 HTML 代码时常用的方法。sHTML 变量中包含的文本返回到调用代码，然后使用 Response.Write 写入客户端。当然，这还可以表示为直接嵌入不包含 WriteHTML 函数的页面的类似代码。此代码的问题是，ASP 和 Visual Basic 使用的字符串数据类型（BSTR 或 Basic 字符串）实际上无法更改长度。这意味着每当字符串长度更改时，内存中字符串的原始表示形式都将遭到破坏，而且将创建一个包含新字符串数据的新的表示形式：这将增加分配内存和解除分配内存的操作。当然，ASP 和 Visual Basic 已为您解决了这一问题，因此实际开销不会立即显现出来。分配内存和解除分配内存要求基本运行时代码解除各个专用锁定，因此需要大量开销。当字符串变得很大并且有大块内存要被快速连续地分配和解除分配时，此问题变得尤为明显，就像在大型字符串连接期间出现的情况一样。尽管这一问题对单用户环境的影响不大，但在服务器环境（例如，在 Web 服务器上运行的 ASP 应用程序）中，它将导致严重的性能和可缩放性问题。下面，我们回到上述代码片段：此代码中要执行多少个字符串分配操作？答案是 16 个。在这种情况下，“&”运算符的每次应用都将导致变量 sHTML 所指的字符串被破坏和重新创建。前面已经提到，字符串分配的开销很大，并且随着字符串的增大而增加，因此，我们可以对上述代码进行改进。快捷的解决方案
有两种方法可以缓解字符串连接的影响，第一种方法是尝试减小要处理的字符串的大小，第二种方法是尝试减少执行字符串分配操作的数目。请参见下面所示的 WriteHTML 代码的修订版本。
Function WriteHTML( Data )
Dim nRep
For nRep = 0 to 99
sHTML = sHTML & ( vbcrlf _
& "" & (nRep + 1) & "" _
& Data( 0, nRep ) & "" _
& Data( 1, nRep ) & "" _
& Data( 2, nRep ) & "" _
& Data( 3, nRep ) & "" _
& Data( 4, nRep ) & "" _
& Data( 5, nRep ) & "" ) Next
WriteHTML = sHTML
End Function
乍一看，可能很难发现这段代码与上一个代码示例的差别。其实，此代码只是在 sHTML = sHTML & 后的内容外面加上了括号。这实际上是通过更改优先顺序，来减小大多数字符串连接操作中处理的字符串大小。在最初的代码示例中，ASP 编译器将查看等号右边的表达式，并从左到右进行计算。结果，每次重复都要进行 16 个连接操作，这些操作针对不断增长的 sHTML 进行。在新版本中，我们提示编译器更改操作顺序。现在，它将按从左到右、从括号内到括号外的顺序计算表达式。此技术使得每次重复包括 15 个连接操作，这些操作针对的是不会增长的较小字符串，只有一个是针对不断增长的大的 sHTML。图 1 显示了这种优化方法与标准连接方法在内存使用模式方面的比较。
图 1：标准连接与加括号连接在内存使用模式方面的比较
在特定情况下，使用括号可以对性能和可缩放性产生十分显著的影响，后文将对此进行进一步的说明。StringBuilder
我们已经找到了解决字符串连接问题的快捷方法，在多数情况下，此方法可以达到性能和投入的最佳平衡。但是，如果要进一步提高构建大型字符串的性能，需要采用第二种方法，即减少字符串分配操作的数目。为此，需要使用 StringBuilder。StringBuilder 是一个类，用于维护可配置的字符串缓冲区，管理插入到此缓冲区的新文本片断，并仅在文本长度超出字符串缓冲区长度时对字符串进行重新分配。Microsoft .NET 框架免费提供了这样一个类 (System.Text.StringBuilder)，并建议在该环境下进行的所有字符串连接操作中使用它。在 ASP 和传统的 Visual Basic 环境中，我们无法访问此类，因此需要自行创建。下面是使用 Visual Basic 6.0 创建的 StringBuilder 类示例（为简洁起见，省略了错误处理代码）。
Option Explicit ' 默认的缓冲区初始大小和增长系数
Private Const DEF_INITIALSIZE As Long = 1000
Private Const DEF_GROWTH As Long = 1000 ' 缓冲区大小和增长
Private m_nInitialSize As Long Private m_nGrowth As Long ' 缓冲区和缓冲区计数器
Private m_sText As String
Private m_nSize As Long Private m_nPos As Long
Private Sub Class_Initialize() ' 设置大小和增长的默认值
m_nInitialSize = DEF_INITIALSIZE
m_nGrowth = DEF_GROWTH ' 初始化缓冲区
InitBuffer End Sub ' 设置初始大小和增长数量
Public Sub Init(ByVal InitialSize As Long, ByVal Growth As Long)
If InitialSize > 0 Then m_nInitialSize = InitialSize
If Growth > 0 Then m_nGrowth = Growth
End Sub ' 初始化缓冲区
Private Sub InitBuffer()
m_nSize = -1
m_nPos = 1 End Sub ' 增大缓冲区
Private Sub Grow(Optional MinimimGrowth As Long) ' 初始化缓冲区（如有必要）
If m_nSize = -1 Then
m_nSize = m_nInitialSize
m_sText = Space$(m_nInitialSize)
Else ' 只是增长
Dim nGrowth As Long
nGrowth = IIf(m_nGrowth > MinimimGrowth,
m_nGrowth, MinimimGrowth)
m_nSize = m_nSize + nGrowth
m_sText = m_sText & Space$(nGrowth)
End If End Sub ' 将缓冲区大小调整到当前使用的大小
Private Sub Shrink()
If m_nSize > m_nPos Then
m_nSize = m_nPos - 1
m_sText = RTrim$(m_sText)
End If End Sub ' 添加单个文本字符串
Private Sub AppendInternal(ByVal Text As String)
If (m_nPos + Len(Text)) > m_nSize Then Grow Len(Text)
Mid$(m_sText, m_nPos, Len(Text)) = Text
m_nPos = m_nPos + Len(Text) End Sub ' 添加一些文本字符串
Public Sub Append(ParamArray Text())
Dim nArg As Long
For nArg = 0 To UBound(Text)
AppendInternal CStr(Text(nArg))
Next nArg End Sub ' 返回当前字符串数据并调整缓冲区大小
Public Function ToString() As String
If m_nPos > 0 Then
Shrink
ToString = m_sText
Else
ToString = ""
End If
End Function ' 清除缓冲区并重新初始化
Public Sub Clear()
InitBuffer
End Sub
此类中使用的基本原则是，在类级别将变量 (m_sText) 用作字符串缓冲区，并使用 Space$ 函数以空格字符填充此缓冲区以将其设置为特定的大小。如果要将更多文本与现有文本连接在一起，则在检查缓冲区的大小足以存放新文本后，使用 Mid$ 函数在正确位置插入文本。ToString 函数将返回当前存储在缓冲区中的文本，并将缓冲区的大小调整为能够容纳此文本的正确长度。使用 StringBuilder 的 ASP 代码如下所示：
Function WriteHTML( Data )
Dim oSB Dim nRep
Set oSB = Server.CreateObject( "StringBuilderVB.StringBuilder" ) ' 用大小和增长系数初始化缓冲区
oSB.Init 15000, 7500
For nRep = 0 to 99
oSB.Append "", (nRep + 1), "", _
Data( 0, nRep ), "", _
Data( 1, nRep ), "", _
Data( 2, nRep ), "", _
Data( 3, nRep ), "", _
Data( 4, nRep ), "", _
Data( 5, nRep ), "" Next
WriteHTML = oSB.ToString()
Set oSB = Nothing
End Function
使用 StringBuilder 需要一定的开销，因为每次使用此类时都必须创建它的实例，并且在创建第一个类实例时必须加载包含此类的 DLL。对 StringBuilder 实例进行额外方法调用时也需要开销。使用加括号的“&”方法时，StringBuilder 如何执行取决于多个因素，包括连接的数目、要构建的字符串的大小以及选择的 StringBuilder 字符串缓冲区的初始化参数的性能。请注意，在多数情况下，将缓冲区中所需的空间量估计得略高一些要远远好于让其不断增长。 内置方法
ASP 包含一种非常快捷的创建 HTML 代码的方法，只需多次调用 Response.Write。Write 函数使用隐式优化的字符串缓冲区，此缓冲区能够提供非常优秀的性能特性。修改后的 WriteHTML 代码如下所示：
Function WriteHTML( Data )
Dim nRep
For nRep = 0 to 99
Response.Write "" Response.Write (nRep + 1)
Response.Write ""
Response.Write Data( 0, nRep )
Response.Write ""
Response.Write Data( 1, nRep )
Response.Write "" Response.Write Data( 2, nRep )
Response.Write ""
Response.Write Data( 3, nRep )
Response.Write ""
Response.Write Data( 4, nRep )
Response.Write ""
Response.Write Data( 5, nRep )
Response.Write ""
Next
End Function
虽然这段代码很可能为我们提供最佳的性能和可缩放性，但在某种程度上已经破坏了封装，因为现在会将函数内部的代码直接写入 Response 流，所以调用代码丧失了一定程度的控制权。另外，移动此代码（例如，移入 COM 组件）将变得更加困难，因为此函数与 Response 流存在依赖关系。 测试
上面提到的四种方法分别通过一个简单的 ASP 页面（包含一个由虚拟字符串数组提供数据的单个表格）进行了测试。我们使用 Application Center Test? (ACT) 从单个客户端（Windows? XP Professional，PIII-850MHz，512MB RAM）针对 100Mb/sec 网络中的单个服务器（Windows 2000 Advanced Server，双 PIII-1000MHz，256MB RAM）执行了测试。ACT 配置为使用 5 个线程，以模拟 5 个用户连接至网站时的负载。每个测试都包括 20 秒预热时间和随后的 100 秒负载时间，在负载期间创建了尽可能多的请求。 通过更改主表格循环中的重复次数，针对不同数目的连接操作重复运行测试，如 WriteHTML 函数中的代码片断所示。运行的每个测试都使用上文提到的四种不同的方法执行。 结果
下面的一系列图表显示了各种方法对整个应用程序吞吐量的影响，以及 ASP 页面的响应时间。通过这些图表，我们可以了解应用程序支持的请求数目，以及用户等待页面下载至浏览器所需的时间。
表 1：使用的连接方法缩写的说明
方法缩写
说明
RESP
内置 Response.Write 方法
CAT
标准连接（“&”）方法
PCAT
加括号的连接（“&”）方法
BLDR
StringBuilder 方法
在模拟典型 ASP 应用程序工作负荷方面，此测试与实际情况相差甚远，从表 2 中可以明显看到，即使重复 420 次，此页面仍不是特别大。现在很多复杂的 ASP 页面在这些数字上都是比较高的，设置有可能超出此测试范围的限制。
表 2：测试示例的页面大小和连接数目
重复次数
连接数目
页面大小（以字节为单位）
15
240
2,667
30
480
4,917
45
720
7,167
60
960
9,417
75
1,200
11,667
120
1,920
18,539
180
2,880
27,899
240
3,840
37,259
300
4,800
46,619
360
5,760
55,979
420
6,720
62,219
图 2：吞吐量结果图
从图 2 的图表中可以看到，正如我们所预期的，多重 Response.Write 方法 (RESP) 在测试的整个重复测试范围中为我们提供了最佳的吞吐量。但令人惊讶的是，标准字符串连接方法 (CAT) 的下降如此巨大，而加括号的方法 (PCAT) 在重复执行 300 多次时性能依旧要好很多。在大约重复 220 次之处，字符串缓存带来的性能提高超过了 StringBuilder 方法 (BLDR) 固有的开销，在这一点以上，在此 ASP 页面中使用 StringBuilder 所需的额外开销是值得的。
图 3：响应时间结果图
图 4：省略 CAT 的响应时间结果图
图 3 和图 4 中的图表显示了按“到第一字节的时间”测量的响应时间（以毫秒为单位）。因为标准字符串连接方法 (CAT) 的响应时间增加过快，所以又提供了未包括此方法的图表（图 4），以便分析其他方法之间的差异。有一点值得注意，多重 Response.Write 方法 (RESP) 和 StringBuilder 方法 (BLDR) 随重复次数的增加呈现一种近似线性的增长，而标准连接方法 (CAT) 和加括号的方法 (PCAT) 则在超过一定的阈值之后开始迅速增加。 小结
本文着重讲述了如何在 ASP 环境中应用不同的字符串构建技术，这些内容同样适用于所有使用 Visual Basic 代码创建大型字符串的方案，例如手动创建 XML 文档。以下原则可以帮助您确定哪种方法最适合您的需要。
首先尝试加括号的“&”方法，尤其是在处理现有代码时。这种方法对代码结构的影响微乎其微，但您会发现应用程序的性能将显著增强，甚至会超出预定目标。 在不破坏所需的封装级别的情况下使用 Response.Write。使用此方法，可以避免不必要的内存内字符串处理，从而提供最佳的性能。
使用 StringBuilder 构建真正大型或连接数目较多的字符串。
尽管您可能未看到本文所示的这种性能增长，但我已在真实的 ASP Web 应用程序中使用了这些技巧，只需要很少的额外投入就可以在性能和可缩放性方面获得很大的提高。
第三课.提高ASP性能的最佳选择
Developer Services, Microsoft UK
2003年3月
适用于：
Microsoft? Active Server Pages?
Microsoft Visual Basic?摘要：大多数 Active Server Pages (ASP) 应用程序都要通过字符串连接来创建呈现给用户的 HTML 格式的数据。本文对几种创建此 HTML 数据流的方法进行了比较，在特定情况下，某些方法在性能方面要优于其他方法。本文假定您已经具备一定的 ASP 和 Visual Basic 编程方面的知识。
简介
编写 ASP 页面时，开发人员实际上是创建一个格式化的文本流，通过 ASP 提供的 Response 对象写入 Web 客户端。创建此文本流的方法有多种，而您选择的方法将对 Web 应用程序的性能和可缩放性产生很大影响。很多次，在我帮助客户优化其 Web 应用程序的性能时，发现其中一个比较有效的方法是更改 HTML 流的创建方式。本文将介绍几种常用技术，并测试它们对一个简单的 ASP 页面的性能所产生的影响。 ASP 设计
许多 ASP 开发人员都遵循良好的软件工程原则，尽可能地将其代码模块化。这种设计通常使用一些包含文件，这些文件中包含对页面的特定不连续部分进行格式化生成的函数。这些函数的字符串输出（通常是 HTML 表格代码）可以通过各种组合创建一个完整的页面。某些开发人员对此方法进行了改进，将这些 HTML 函数移到 Visual Basic COM 组件中，希望充分利用已编译的代码提供的额外性能。尽管这种设计方法很不错，但创建组成这些不连续 HTML 代码组件的字符串所使用的方法将对 Web 站点的性能和可缩放性产生很大的影响，无论实际的操作是在 ASP 包含文件中执行还是在 Visual Basic COM 组件中执行。字符串连接
请看以下 WriteHTML 函数的代码片断。名为 Data 的参数只是一个字符串数组，其中包含一些要格式化为表格结构的数据（例如，从数据库返回的数据）。
Function WriteHTML( Data )
Dim nRep For nRep = 0 to 99
sHTML = sHTML & vbcrlf _
& "" & (nRep + 1) & "" _
& Data( 0, nRep ) & "" _
& Data( 1, nRep ) & "" _
& Data( 2, nRep ) & "" _
& Data( 3, nRep ) & "" _
& Data( 4, nRep ) & "" _
& Data( 5, nRep ) & "" Next
WriteHTML = sHTML
End Function
这是很多 ASP 和 Visual Basic 开发人员创建 HTML 代码时常用的方法。sHTML 变量中包含的文本返回到调用代码，然后使用 Response.Write 写入客户端。当然，这还可以表示为直接嵌入不包含 WriteHTML 函数的页面的类似代码。此代码的问题是，ASP 和 Visual Basic 使用的字符串数据类型（BSTR 或 Basic 字符串）实际上无法更改长度。这意味着每当字符串长度更改时，内存中字符串的原始表示形式都将遭到破坏，而且将创建一个包含新字符串数据的新的表示形式：这将增加分配内存和解除分配内存的操作。当然，ASP 和 Visual Basic 已为您解决了这一问题，因此实际开销不会立即显现出来。分配内存和解除分配内存要求基本运行时代码解除各个专用锁定，因此需要大量开销。当字符串变得很大并且有大块内存要被快速连续地分配和解除分配时，此问题变得尤为明显，就像在大型字符串连接期间出现的情况一样。尽管这一问题对单用户环境的影响不大，但在服务器环境（例如，在 Web 服务器上运行的 ASP 应用程序）中，它将导致严重的性能和可缩放性问题。下面，我们回到上述代码片段：此代码中要执行多少个字符串分配操作？答案是 16 个。在这种情况下，“&”运算符的每次应用都将导致变量 sHTML 所指的字符串被破坏和重新创建。前面已经提到，字符串分配的开销很大，并且随着字符串的增大而增加，因此，我们可以对上述代码进行改进。快捷的解决方案
有两种方法可以缓解字符串连接的影响，第一种方法是尝试减小要处理的字符串的大小，第二种方法是尝试减少执行字符串分配操作的数目。请参见下面所示的 WriteHTML 代码的修订版本。
Function WriteHTML( Data )
Dim nRep
For nRep = 0 to 99
sHTML = sHTML & ( vbcrlf _
& "" & (nRep + 1) & "" _
& Data( 0, nRep ) & "" _
& Data( 1, nRep ) & "" _
& Data( 2, nRep ) & "" _
& Data( 3, nRep ) & "" _
& Data( 4, nRep ) & "" _
& Data( 5, nRep ) & "" ) Next
WriteHTML = sHTML
End Function
乍一看，可能很难发现这段代码与上一个代码示例的差别。其实，此代码只是在 sHTML = sHTML & 后的内容外面加上了括号。这实际上是通过更改优先顺序，来减小大多数字符串连接操作中处理的字符串大小。在最初的代码示例中，ASP 编译器将查看等号右边的表达式，并从左到右进行计算。结果，每次重复都要进行 16 个连接操作，这些操作针对不断增长的 sHTML 进行。在新版本中，我们提示编译器更改操作顺序。现在，它将按从左到右、从括号内到括号外的顺序计算表达式。此技术使得每次重复包括 15 个连接操作，这些操作针对的是不会增长的较小字符串，只有一个是针对不断增长的大的 sHTML。图 1 显示了这种优化方法与标准连接方法在内存使用模式方面的比较。
图 1：标准连接与加括号连接在内存使用模式方面的比较
在特定情况下，使用括号可以对性能和可缩放性产生十分显著的影响，后文将对此进行进一步的说明。StringBuilder
我们已经找到了解决字符串连接问题的快捷方法，在多数情况下，此方法可以达到性能和投入的最佳平衡。但是，如果要进一步提高构建大型字符串的性能，需要采用第二种方法，即减少字符串分配操作的数目。为此，需要使用 StringBuilder。StringBuilder 是一个类，用于维护可配置的字符串缓冲区，管理插入到此缓冲区的新文本片断，并仅在文本长度超出字符串缓冲区长度时对字符串进行重新分配。Microsoft .NET 框架免费提供了这样一个类 (System.Text.StringBuilder)，并建议在该环境下进行的所有字符串连接操作中使用它。在 ASP 和传统的 Visual Basic 环境中，我们无法访问此类，因此需要自行创建。下面是使用 Visual Basic 6.0 创建的 StringBuilder 类示例（为简洁起见，省略了错误处理代码）。
Option Explicit ' 默认的缓冲区初始大小和增长系数
Private Const DEF_INITIALSIZE As Long = 1000
Private Const DEF_GROWTH As Long = 1000 ' 缓冲区大小和增长
Private m_nInitialSize As Long Private m_nGrowth As Long ' 缓冲区和缓冲区计数器
Private m_sText As String
Private m_nSize As Long Private m_nPos As Long
Private Sub Class_Initialize() ' 设置大小和增长的默认值
m_nInitialSize = DEF_INITIALSIZE
m_nGrowth = DEF_GROWTH ' 初始化缓冲区
InitBuffer End Sub ' 设置初始大小和增长数量
Public Sub Init(ByVal InitialSize As Long, ByVal Growth As Long)
If InitialSize > 0 Then m_nInitialSize = InitialSize
If Growth > 0 Then m_nGrowth = Growth
End Sub ' 初始化缓冲区
Private Sub InitBuffer()
m_nSize = -1
m_nPos = 1 End Sub ' 增大缓冲区
Private Sub Grow(Optional MinimimGrowth As Long) ' 初始化缓冲区（如有必要）
If m_nSize = -1 Then
m_nSize = m_nInitialSize
m_sText = Space$(m_nInitialSize)
Else ' 只是增长
Dim nGrowth As Long
nGrowth = IIf(m_nGrowth > MinimimGrowth,
m_nGrowth, MinimimGrowth)
m_nSize = m_nSize + nGrowth
m_sText = m_sText & Space$(nGrowth)
End If End Sub ' 将缓冲区大小调整到当前使用的大小
Private Sub Shrink()
If m_nSize > m_nPos Then
m_nSize = m_nPos - 1
m_sText = RTrim$(m_sText)
End If End Sub ' 添加单个文本字符串
Private Sub AppendInternal(ByVal Text As String)
If (m_nPos + Len(Text)) > m_nSize Then Grow Len(Text)
Mid$(m_sText, m_nPos, Len(Text)) = Text
m_nPos = m_nPos + Len(Text) End Sub ' 添加一些文本字符串
Public Sub Append(ParamArray Text())
Dim nArg As Long
For nArg = 0 To UBound(Text)
AppendInternal CStr(Text(nArg))
Next nArg End Sub ' 返回当前字符串数据并调整缓冲区大小
Public Function ToString() As String
If m_nPos > 0 Then
Shrink
ToString = m_sText
Else
ToString = ""
End If
End Function ' 清除缓冲区并重新初始化
Public Sub Clear()
InitBuffer
End Sub
此类中使用的基本原则是，在类级别将变量 (m_sText) 用作字符串缓冲区，并使用 Space$ 函数以空格字符填充此缓冲区以将其设置为特定的大小。如果要将更多文本与现有文本连接在一起，则在检查缓冲区的大小足以存放新文本后，使用 Mid$ 函数在正确位置插入文本。ToString 函数将返回当前存储在缓冲区中的文本，并将缓冲区的大小调整为能够容纳此文本的正确长度。使用 StringBuilder 的 ASP 代码如下所示：
Function WriteHTML( Data )
Dim oSB Dim nRep
Set oSB = Server.CreateObject( "StringBuilderVB.StringBuilder" ) ' 用大小和增长系数初始化缓冲区
oSB.Init 15000, 7500
For nRep = 0 to 99
oSB.Append "", (nRep + 1), "", _
Data( 0, nRep ), "", _
Data( 1, nRep ), "", _
Data( 2, nRep ), "", _
Data( 3, nRep ), "", _
Data( 4, nRep ), "", _
Data( 5, nRep ), "" Next
WriteHTML = oSB.ToString()
Set oSB = Nothing
End Function
使用 StringBuilder 需要一定的开销，因为每次使用此类时都必须创建它的实例，并且在创建第一个类实例时必须加载包含此类的 DLL。对 StringBuilder 实例进行额外方法调用时也需要开销。使用加括号的“&”方法时，StringBuilder 如何执行取决于多个因素，包括连接的数目、要构建的字符串的大小以及选择的 StringBuilder 字符串缓冲区的初始化参数的性能。请注意，在多数情况下，将缓冲区中所需的空间量估计得略高一些要远远好于让其不断增长。 内置方法
ASP 包含一种非常快捷的创建 HTML 代码的方法，只需多次调用 Response.Write。Write 函数使用隐式优化的字符串缓冲区，此缓冲区能够提供非常优秀的性能特性。修改后的 WriteHTML 代码如下所示：
Function WriteHTML( Data )
Dim nRep
For nRep = 0 to 99
Response.Write "" Response.Write (nRep + 1)
Response.Write ""
Response.Write Data( 0, nRep )
Response.Write ""
Response.Write Data( 1, nRep )
Response.Write "" Response.Write Data( 2, nRep )
Response.Write ""
Response.Write Data( 3, nRep )
Response.Write ""
Response.Write Data( 4, nRep )
Response.Write ""
Response.Write Data( 5, nRep )
Response.Write ""
Next
End Function
虽然这段代码很可能为我们提供最佳的性能和可缩放性，但在某种程度上已经破坏了封装，因为现在会将函数内部的代码直接写入 Response 流，所以调用代码丧失了一定程度的控制权。另外，移动此代码（例如，移入 COM 组件）将变得更加困难，因为此函数与 Response 流存在依赖关系。 测试
上面提到的四种方法分别通过一个简单的 ASP 页面（包含一个由虚拟字符串数组提供数据的单个表格）进行了测试。我们使用 Application Center Test? (ACT) 从单个客户端（Windows? XP Professional，PIII-850MHz，512MB RAM）针对 100Mb/sec 网络中的单个服务器（Windows 2000 Advanced Server，双 PIII-1000MHz，256MB RAM）执行了测试。ACT 配置为使用 5 个线程，以模拟 5 个用户连接至网站时的负载。每个测试都包括 20 秒预热时间和随后的 100 秒负载时间，在负载期间创建了尽可能多的请求。 通过更改主表格循环中的重复次数，针对不同数目的连接操作重复运行测试，如 WriteHTML 函数中的代码片断所示。运行的每个测试都使用上文提到的四种不同的方法执行。 结果
下面的一系列图表显示了各种方法对整个应用程序吞吐量的影响，以及 ASP 页面的响应时间。通过这些图表，我们可以了解应用程序支持的请求数目，以及用户等待页面下载至浏览器所需的时间。
表 1：使用的连接方法缩写的说明
方法缩写
说明
RESP
内置 Response.Write 方法
CAT
标准连接（“&”）方法
PCAT
加括号的连接（“&”）方法
BLDR
StringBuilder 方法
在模拟典型 ASP 应用程序工作负荷方面，此测试与实际情况相差甚远，从表 2 中可以明显看到，即使重复 420 次，此页面仍不是特别大。现在很多复杂的 ASP 页面在这些数字上都是比较高的，设置有可能超出此测试范围的限制。
表 2：测试示例的页面大小和连接数目
重复次数
连接数目
页面大小（以字节为单位）
15
240
2,667
30
480
4,917
45
720
7,167
60
960
9,417
75
1,200
11,667
120
1,920
18,539
180
2,880
27,899
240
3,840
37,259
300
4,800
46,619
360
5,760
55,979
420
6,720
62,219
图 2：吞吐量结果图
从图 2 的图表中可以看到，正如我们所预期的，多重 Response.Write 方法 (RESP) 在测试的整个重复测试范围中为我们提供了最佳的吞吐量。但令人惊讶的是，标准字符串连接方法 (CAT) 的下降如此巨大，而加括号的方法 (PCAT) 在重复执行 300 多次时性能依旧要好很多。在大约重复 220 次之处，字符串缓存带来的性能提高超过了 StringBuilder 方法 (BLDR) 固有的开销，在这一点以上，在此 ASP 页面中使用 StringBuilder 所需的额外开销是值得的。
图 3：响应时间结果图
图 4：省略 CAT 的响应时间结果图
图 3 和图 4 中的图表显示了按“到第一字节的时间”测量的响应时间（以毫秒为单位）。因为标准字符串连接方法 (CAT) 的响应时间增加过快，所以又提供了未包括此方法的图表（图 4），以便分析其他方法之间的差异。有一点值得注意，多重 Response.Write 方法 (RESP) 和 StringBuilder 方法 (BLDR) 随重复次数的增加呈现一种近似线性的增长，而标准连接方法 (CAT) 和加括号的方法 (PCAT) 则在超过一定的阈值之后开始迅速增加。 小结
本文着重讲述了如何在 ASP 环境中应用不同的字符串构建技术，这些内容同样适用于所有使用 Visual Basic 代码创建大型字符串的方案，例如手动创建 XML 文档。以下原则可以帮助您确定哪种方法最适合您的需要。
首先尝试加括号的“&”方法，尤其是在处理现有代码时。这种方法对代码结构的影响微乎其微，但您会发现应用程序的性能将显著增强，甚至会超出预定目标。 在不破坏所需的封装级别的情况下使用 Response.Write。使用此方法，可以避免不必要的内存内字符串处理，从而提供最佳的性能。
使用 StringBuilder 构建真正大型或连接数目较多的字符串。
尽管您可能未看到本文所示的这种性能增长，但我已在真实的 ASP Web 应用程序中使用了这些技巧，只需要很少的额外投入就可以在性能和可缩放性方面获得很大的提高。
第三课.提高ASP性能的最佳选择ASP开发人员为了在他们的设计项目中获得更好的性能和可扩展性而不断努力。幸运地是，有许多书籍和站点在这方面提供了很好的建议。但是这些建议的基础都是从ASP平台工作的结构上所得出的结论，对实际获得的性能的提高没有量的测量。由于这些建议需要更加复杂的编码过程并降低了编码的可读性，开发人员就只能在看不到实际运行效果的情况下，独自衡量为了提高他们ASP应用程序的性能是否值得付出这些代价。
本文分为两大部分，我将介绍一些性能测试结果，帮助开发人员来确定某一特定举措是否不仅对将来的项目来说是值得的，并且能够对原来的项目进行更新。在第一部分我将回顾一些ASP开发的基础性问题。在第二部分，将涉及一些最优化ADO函数，并将它们的结果与调用VB COM对象执行相同ADO函数的ASP页面进行比较。这些结果很让人开眼界，甚至有些时候是很令人吃惊的。
在本文中，我们将回答以下问题：
* 将ASP生成的内容写入响应流中最有效的方法是什么？
* 是否应该开启缓冲器？
* 是否应该考虑向ASP代码中增加注释？
* 是否应该为页面明确地设置默认语言？
* 如果不需要，是否应该关闭Session 状态？
* 是否应该把脚本逻辑放在子程序和函数区中？
* 使用包含文件有什么影响？
* 执行错误处理时会施加什么样的负载？
* 设置一个上下文处理是否对性能有影响？
所有测试都是用Microsoft的Web应用程序重点工具(WAST)来进行的，这是一个免费的工具，可以在这里找到。我用WAST创建了一个简单的test 脚本，反复调用下面所描述的ASP页面测试（每个超过70，000次）。反应的时间基于平均最后字节总时间(TTLB), 也就是从最初请求的时间到工具从服务器接收最后一位数据的时间。我们的测试服务器是一个Pentium 166，内存为196MB，客户机为Pentium 450，内存为256MB。你也许会想这些机器的性能并不算很高级，但是不要忘了，我们并不是要测试服务器的容量，我们只是要测试服务器每次处理一个页面所用的时间。测试期间这些机器不做其它工作。WAST 测试脚本、测试报告以及所有的ASP测试页面都包含在ZIP文件中，你可以自己进行回顾和测试。
将ASP生成的内容写入响应流中最有效的方法是什么？
使用ASP的一个最主要原因是在服务器上生成动态内容。所以很明显，我们测试的起点是确定将动态内容发送到响应流中的最适合的方式。在多种选择中，有两个是最基本的：一是使用内联ASP标记，另一个是使用Response.Write 语句。
为测试这些选择，我们创建了一个简单的ASP页面，其中定义了一些变量，然后将它们的值插入表格中。虽然这个页面很简单也不是很实用，但它允许我们分离并测试一些单独的问题。
使用ASP内联标记
第一个测试包括使用内联ASP标记＜ %= x % ＞，其中x是一个已赋值的变量。到目前为止，这个方法是最容易执行的，并且它使页面的HTML部分保持一种易于阅读和维护的格式。
＜ % OPTION EXPLICIT
Dim FirstName
Dim LastName
Dim MiddleInitial
Dim Address
Dim City
Dim State
Dim PhoneNumber
Dim FaxNumber
Dim EMail
Dim BirthDate
FirstName = "John"
MiddleInitial = "Q"
LastName = "Public"
Address = "100 Main Street"
City = "New York"
State = "NY"
PhoneNumber = "1-212-555-1234"
FaxNumber = "1-212-555-1234"
EMail = "john@public.com"
BirthDate = "1/1/1950"
% ＞
＜ HTML ＞
＜ HEAD ＞
＜ TITLE ＞Response Test＜ / TITLE ＞
＜ /HEAD ＞
＜ BODY ＞
＜ H1 ＞Response Test＜ /H1 ＞
＜ TABLE ＞
＜ tr ＞＜ td ＞＜ b ＞First Name:＜ /b ＞＜ /td ＞＜ td ＞＜ %= FirstName % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Middle Initial:＜ /b ＞＜ /td ＞＜ td ＞＜ %= MiddleInitial % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Last Name:＜ /b ＞＜ /td ＞＜ td ＞＜ %= LastName % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Address:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Address % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞City:＜ /b ＞＜ /td ＞＜ td ＞＜ %= City % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞State:＜ /b ＞＜ /td ＞＜ td ＞＜ %= State % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Phone Number:＜ /b ＞＜ /td ＞＜ td ＞＜ %= PhoneNumber % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Fax Number:＜ /b ＞＜ /td ＞＜ td ＞＜ %= FaxNumber % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞EMail:＜ /b ＞＜ /td ＞＜ td ＞＜ %= EMail % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Birth Date:＜ /b ＞＜ /td ＞＜ td ＞＜ %= BirthDate % ＞＜ /td ＞＜ /tr ＞
＜ /TABLE ＞
＜ /BODY ＞
＜ /HTML ＞
/app1/response1.asp的完整代码
以前的最佳（反应速度） = 8.28 msec/page
在HTML的每一行使用Response.Write 语句
许多比较好的学习文档建议避免使用前面的那种方法。其主要理由是，在输出页面和处理页面施加反应时间的过程中，如果web 服务器不得不在发送纯HTML和处理脚本之间进行转换，就会发生一种被称为上下文转换的问题。大部分程序员一听到这里，他们的第一反应就是将原始的HTML的每一行都包装在Response.Write函数中。
…
Response.Write("＜ html ＞")
Response.Write("＜ head ＞")
Response.Write(" ＜ title ＞Response Test＜ /title ＞")
Response.Write("＜ /head ＞")
Response.Write("＜ body ＞")
Response.Write("＜ h1 ＞Response Test＜ /h1 ＞")
Response.Write("＜ table ＞")
Response.Write("＜ tr ＞＜ td ＞＜ b ＞First Name:＜ /b ＞＜ /td ＞＜ td ＞" & FirstName & "＜ /td ＞＜ /tr ＞")
Response.Write("＜ tr ＞＜ td ＞＜ b ＞Middle Initial:＜ /b ＞＜ /td ＞＜ td ＞" & MiddleInitial & "＜ /td ＞＜ /tr ＞")
…
/app1/response2.asp的片段
以前的最佳（反应速度） = 8.28 msec/page
反应时间 = 8.08 msec/page
差= -0.20 msec (减少 2.4%)
我们可以看到，使用这种方法与使用内联标记的方法相比在性能上获得的收益非常小，这也许是因为页面给服务器装载了一大堆小的函数调用。这种方法最大的缺点是，由于现在HTML都嵌入脚本中，所以脚本代码变得更加冗长，更加难以阅读和维护。
使用包装函数
当我们试图使用Response.Write 语句这种方法时，最令人灰心的发现可能就是Response.Write 函数不能在每行的结尾处放置一个CRLF 。因此，当你从浏览器中阅读源代码时，本来布置得非常好的HTML，现在成了没有结束的一行。我想，你的下一个发现可能会更令你恐怖：在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 msec/page
反应时间= 10.11 msec/page
差 = +2.03 msec (增加 25.1%)
当然，由于这种方法有效地使函数调用次数加倍，其对性能的影响也很明显，因此要不惜一切代价避免。具有讽刺意味的是CRLF也向反应流中为每行增加了2个字节，而这是浏览器不需要呈现到页面上的。格式化良好的HTML所做的一切就是让你的竞争者更容易阅读你的HTML源代码并理解你的设计。
将连续的Response.Write 连接到一个单独语句中
不考虑我们前面用包装函数进行的测试，下一个合乎逻辑的步骤就是从单独的Response.Write 语句中提取出所有的字符串，将它们连接到一个单独语句中，这样就减少了函数调用的次数，极大地提高了页面的性能。
…
Response.Write("＜ html ＞" & _
"＜ head ＞" & _
"＜ title ＞Response Test＜ /title ＞" & _
"＜ /head ＞" & _
"＜ body ＞" & _
"＜ h1 ＞Response Test＜ /h1 ＞" & _
"＜ table ＞" & _
"＜ tr ＞＜ td ＞＜ b ＞First Name:＜ /b ＞＜ /td ＞＜ td ＞" & FirstName & "＜ /td ＞＜ /tr ＞" & _
…
"＜ tr ＞＜ td ＞＜ b ＞Birth Date:＜ /b ＞＜ /td ＞＜ td ＞" & BirthDate & "＜ /td ＞＜ /tr ＞" & _
"＜ /table ＞" & _
"＜ /body ＞" & _
"＜ /html ＞")
/app1/response3.asp的片段
以前的最佳（反应速度）= 8.08 msec/page
反应时间 = 7.05 msec/page
差 = -1.03 msec (减少12.7%)
目前，这是最优化的配置。
将连续的Response.Write 连接到一个单独语句中，在每行结尾处增加一个CRLF
考虑到那些要求他们的源代码从浏览器中看要很纯粹的人，我用vbCRLF 常量在前面测试中每行的结尾处插入了一些回车，然后重新运行。
…
Response.Write("＜ html ＞" & vbCRLF & _
"＜ head ＞" & vbCRLF & _
" ＜ title ＞Response Test＜ /title ＞" & vbCRLF & _
"＜ /head ＞" & vbCRLF & _
…
/app1/response5.asp的片段
前面的最佳（反应速度）= 7.05 msec/page
反应时间= 7.63 msec/page
差 = +0.58 msec (增加 8.5%)
运行的结果在性能上有一点降低，这也许是由于额外的串联和增加的字符量。
回顾和观测
从前面有关ASP输出的测试中可以得出一些规则：
* 避免内联ASP的过多使用。
* 总是将连续Response.Write 语句连接进一个单独语句内。
* 永远不要在Response.Write 周围使用包装函数来附加CRLF。
* 如果必须格式化HTML输出，直接在Response.Write 语句内附加CRLF。
是否应该开启缓冲器？
通过脚本程序启动缓冲器
在ASP脚本的顶部包含Response.Buffer=True ，IIS就会将页面的内容缓存。
＜ % OPTION EXPLICIT
Response.Buffer = true
Dim FirstName
…
/app1/buffer__1.asp的片段
以前的最佳（反应时间）= 7.05 msec/page
反应时间 = 6.08 msec/page
差= -0.97 msec (降低13.7%)
性能得到了极大提高。但是等等，还能有更好的。
通过服务器配置启动缓冲器
虽然在IIS 5.0中缓冲器是被默认启动的，但是在IIS 4.0中还必须手动来启动它。这时要找到站点的Properties 对话框，在那里，从Home Directory 标签中选择配置按钮。然后在"App options"下选择"enable buffering" 。对于这个测试，Response.Buffer 语句从脚本中被移走了。
以前的最佳= 7.05 msec/page
反应时间 = 5.57 msec/page
差= -1.48 msec (降低 21.0%)
目前，这是我们所得到的最快反应了，比我们以前最好情况下的反应时间还要降低21%。从现在开始，我们以后的测试都要把这个反应时间作为基准值。
回顾及观测
缓冲器是提高性能的好方法，所以把缓冲器设置成服务器的默认值很有必要。如果因为某些原因，页面不能正确地使缓冲器运行，只需要Response.Buffer=False 命令即可。缓冲器的一个缺点是在整个页面处理完之前，用户从服务器看不到任何东西。因此，在复杂页面的处理期间，偶而调用一次Response.Flush 来更新用户是个好主意。
现在在我们的规则中又增加了一条：总是通过服务器设置开启缓冲器。
是否应该考虑向ASP代码中增加注释？
大部分HTML开发人员都知道包含HTML注释不是个好主意，首先会增加传输数据的规模，其次它们只是向别的开发人员提供有关你页面组织的信息。但是ASP页面上的注释又如何呢？它们从来不离开服务器，但也确实要增加页面的规模，因此必须用ASP进行分解。
在这次的测试中，我们增加20条注释，每条有80个字符，总共有1600个字符。
＜ % OPTION EXPLICIT
'-------------------------------------------------------------------------------
… 20 lines …
'-------------------------------------------------------------------------------
Dim FirstName
…
/app2/comment_1.asp片段
基准= 5.57 msec/page
反应时间= 5.58 msec/page
差 = +0.01 msec (增加 0.1%)
测试的结果是惊人的。虽然注释几乎相当于文件本身的两倍，但是它们的存在并没有给反应时间带来很大的影响。所以说我们可以遵循以下规则：
只要使用适度，ASP注释对性能的影响很小或根本没有影响。
是否应该为页面明确地设置默认语言？
IIS处理VBScript是默认的设置，但是我看到，在大多数例子中还是用＜ %@LANGUAGE=VBSCRIPT% ＞声明将语言明确地设置为VBScript 。我们的下一个测试将检验这个声明的存在对性能有什么影响。
＜ %@ LANGUAGE=VBSCRIPT % ＞
＜ % OPTION EXPLICIT
Dim FirstName
…
/app2/language1.asp片段。
基准值= 5.57 msec/page
反应时间= 5.64 msec/page
差= +0.07 msec (增加1.2%)
可以看到，包含了语言的声明对性能有一个轻微的影响。因此：
* 设置服务器的默认语言配置以与站点上使用的语言相匹配。
* 除非你使用非默认语言，不要设置语言声明。
如果不需要，是否应该关闭Session 状态？
避免使用IIS的Session上下文有许多理由，那些已经可以独立成为一篇文章。我们现在试图回答的问题是当页面不需要时，关闭Session上下文是否对性能提高有所帮助。从理论上讲应该是肯定的，因为这样一来就不需要用页面例示Session上下文了。
同缓冲器一样，Session状态也有两种配置方法：通过脚本和通过服务器设置。
通过脚本关闭Session上下文
对于这个测试，要关闭页面中的Session上下文，我增加一个Session状态声明。
＜ %@ ENABLESESSIONSTATE = FALSE % ＞
＜ % OPTION EXPLICIT
Dim FirstName
…
/app2/session_1.asp片段。
基准值= 5.57 msec/page
反应时间= 5.46 msec/page
差= -0.11 msec (降低2.0%)
只通过这样一个小小的努力就得到了不错的进步。现在看看第二部分。
通过服务器配置关闭Session 上下文
要在服务器上关闭Session 上下文，请到站点的Properties 对话框。在Home Directory 标签上选择Configuration 按钮。然后在"App options"下取消"enable session state" 的选择。我们在没有ENABLESESSIONSTATE 声明的情况下运行测试。
基准值 = 5.57 msec/page
反应时间= 5.14 msec/page
差= -0.43 msec (降低7.7%)
这是性能的又一个显著提高。所以，我们的规则应是：在不需要的情况下，总是在页面或应用程序的水平上关闭Session状态。
使用Option Explicit 会使性能有实质改变吗？
在一个ASP页面的顶部设置Option Explicit 以要求所有的变量在使用之前都要在页面上进行声明。这有两个原因。首先应用程序可以更快地处理变量的存取。其次，这样可以防止我们无意中错用变量的名字。在这个测试中我们移走Option Explicit 引用和变量的Dim 声明。
基准值 = 5.57 msec/page
反应时间= 6.12 msec/page
差 = +0.55 msec (9.8% 增加)、
尽管有一些代码行从页面中去掉了，反应时间却依然增加了。所以尽管使用Option explicit 有时候费时间，但是在性能上却有很显著的效果。因此我们又可以增加一条规则：在VBScript中总是使用Option explicit。
是否应该把脚本逻辑放在子程序和函数区？
用函数和子程序来组织和管理代码是一个很好的方法，特别是当一个代码区在页面中多次使用的情况。缺点是要在系统上增加一个做相同工作的额外函数调用。子程序和函数的另一个问题是变量的范围。从理论上说，在一个函数区内指定变量更有效。现在我们看看这两个方面如何发生作用。
将Response.Write 语句移入子程序
这个测试只是将Response.Write 语句移入一个子程序区内。
…
CALL writeTable()
SUB writeTable()
Response.Write("＜ html ＞" & _
"＜ head ＞" & _
…
"＜ tr ＞＜ td ＞＜ b ＞EMail:＜ /b ＞＜ /td ＞＜ td ＞" & EMail & "＜ /td ＞＜ /tr ＞" & _
"＜ tr ＞＜ td ＞＜ b ＞Birth Date:＜ /b ＞＜ /td ＞＜ td ＞" & BirthDate & "＜ /td ＞＜ /tr ＞" & _
"＜ /table ＞" & _
"＜ /body ＞" & _
"＜ /html ＞")
END SUB
/app2/function1.asp片段
基准值= 5.57 msec/page
反应时间= 6.02 msec/page
差 = +0.45 msec (8.1% 增加)
同预料中一样，子程序调用给页面带来了额外的负担。
将所有脚本移入子程序中
在这个测试中，Response.write 语句与变量声明都移入一个子程序区中。
＜ % OPTION EXPLICIT
CALL writeTable()
SUB writeTable()
Dim FirstName
…
Dim BirthDate
FirstName = "John"
…
BirthDate = "1/1/1950"
Response.Write("＜ html ＞" & _
"＜ head ＞" & _
" ＜ title ＞Response Test＜ /title ＞" & _
"＜ /head ＞" & _
"＜ body ＞" & _
"＜ h1 ＞Response Test＜ /h1 ＞" & _
"＜ table ＞" & _
"＜ tr ＞＜ td ＞＜ b ＞First Name:＜ /b ＞＜ /td ＞＜ td ＞" & FirstName & "＜ /td ＞＜ /tr ＞" & _
…
"＜ tr ＞＜ td ＞＜ b ＞Birth Date:＜ /b ＞＜ /td ＞＜ td ＞" & BirthDate & "＜ /td ＞＜ /tr ＞" & _
"＜ /table ＞" & _
"＜ /body ＞" & _
"＜ /html ＞")
END SUB
/app2/function2.asp片段
基准值= 5.57 msec/page
反应时间= 5.22 msec/page
差 = -0.35 msec (6.3% 降低)
非常有趣！尽管将变量移到函数范围内增加了额外的函数调用，但实际上却提高了性能。我们又可以增加以下规则：
* 在一个页面上，如果代码要使用一次以上，就将代码封入函数区。
* 适当时候，将变量声明移到函数范围内。
使用包含文件有什么影响？
ASP编程的一个重要功能就是包含来自其它页面的代码。通过这项功能，程序员可以在多个页面上共享函数，使代码更易于维护。缺点在于服务器必须从多个来源组装页面。以下是使用Include文件的两个测试。
使用内联代码的Include 文件
在这个测试中，有一小段代码被移到一个Include 文件中：
＜ % OPTION EXPLICIT
Dim FirstName
…
Dim BirthDate
FirstName = "John"
…
BirthDate = "1/1/1950"
% ＞
＜ !-- #include file="inc1.asp" -- ＞
/app2/include_1.asp片段
基准值 = 5.57 msec/page
反应时间= 5.93 msec/page
差 = +0.36 msec (6.5% 增加)
这不奇怪。使用Include 文件形成了负载。
在函数区使用Include 文件
在这里，代码都包装在一个Include 文件中的子程序里。Include 引用是在页面顶部进行的，在ASP脚本的适当位置调用子程序。
＜ % OPTION EXPLICIT
Dim FirstName
…
Dim BirthDate
FirstName = "John"
…
BirthDate = "1/1/1950"
CALL writeTable()
% ＞
＜ !-- #include file="inc2.asp" -- ＞
/app2/include_2.asp片段
基准值 = 5.57 msec/page
反应时间= 6.08 msec/page
差 =+0.51 msec (9.2% 增加)
这对性能造成的影响比functions调用还大。因此：只有当代码在页面之间共享时才使用Include 文件。
执行错误处理时会形成多大的负载？
对于所有真正的应用程序来说，错误处理都是必要的。这个测试中，通过调用On Error Resume Next函数来调用错误句柄。
＜ % OPTION EXPLICIT
On Error Resume Next
Dim FirstName
…
/app2/error_1.asp片段
基准值 = 5.57 msec/page
反应时间= 5.67 msec/page
差= 0.10 msec (1.8% 增加)
你可以看到，错误句柄带来了代价。我们可以提出以下建议：只有在会发生超出测试或控制能力之外的情况时才使用错误句柄。一个最基本的例子就是使用存取其它资源，如ADO或FileSystem 对象的COM对象。
设置一个上下文处理是否对性能有影响？
当错误发生时，在页面上设置一个上下文处理允许脚本进行反转操作。这是通过在页面上使用处理声明来设置的。
＜ %@ TRANSACTION = REQUIRED % ＞
＜ % OPTION EXPLICIT
Dim FirstName
…
/app2/transact1.asp片段
基准值 = 5.57 msec/page
反应时间= 13.39 msec/page
差 = +7.82 msec (140.4% 增加)
啊！这真实最具有戏剧性的结果。所以请留意以下规则：只有当两个或更多操作被作为一个单元执行时，才使用处理上下文。
结论
本文第一部分的重要之处在于许多小事情的累积。为了强调这个问题，我设置了最后一个测试，在其中进行了我们以前曾经测试过的看来无所谓但实际上有坏影响的所有操作。我包含了许多Response.Write 声明、关闭了缓冲器、设置了默认语言、去掉了Option Explicit 引用并初始化了错误句柄。
＜ %@ LANGUAGE=VBSCRIPT % ＞
＜ %
On Error Resume Next
FirstName = "John"
…
BirthDate = "1/1/1950"
Response.Write("＜ html ＞")
Response.Write("＜ head ＞")
Response.Write(" ＜ title ＞Response Test＜ /title ＞")
Response.Write("＜ /head ＞")
Response.Write("＜ body ＞")
Response.Write("＜ h1 ＞Response Test＜ /h1 ＞")
Response.Write("＜ table ＞")
Response.Write("＜ tr ＞＜ td ＞＜ b ＞First Name:＜ /b ＞＜ /td ＞＜ td ＞" &_
"FirstName & "＜ /td ＞＜ /tr ＞")
…
Response.Write("＜ tr ＞＜ td ＞＜ b ＞Birth Date:＜ /b ＞＜ /td ＞＜ td ＞" &_
" BirthDate & "＜ /td ＞＜ /tr ＞")
Response.Write("＜ /table ＞")
Response.Write("＜ /body ＞")
Response.Write("＜ /html ＞")
% ＞
/app2/final_1.asp片段
基准值 = 5.57 msec/page
反应时间 = 8.85 msec/page
差 = +3.28 msec (58.9% 增加)
听起来可能很明显，但是理解更重要，那就是我们放置在页面上的代码会对性能有影响。页面上的小变化有时会大大地增加反应时间。
规则概括
* 避免内联ASP的过多使用。
* 总是将连续Response.Write 语句连接进一个单独语句内。
* 永远不要在Response.Write 周围使用包装函数以附加CRLF。
* 如果必须格式化HTML输出，直接在Response.Write 语句内附加CRLF。
* 总是通过服务器设置开启缓冲器。
* 只要使用适度，ASP注释对性能的影响很小或根本没有影响。
* 设置服务器的默认语言配置以与站点上使用的语言相匹配。
* 除非你使用非默认语言，不要设置语言声明。
* 在VBScript中总是使用Option explicit 。
* 在不需要的情况下，总是在页面或应用程序的水平上关闭Session状态。
* 只有当代码在页面之间共享时才使用Include 文件。
* 在一个页面上，如果代码要使用一次以上，就将代码封入函数区。
* 适当时候，将变量声明移到函数范围内。
* 只有会发生超出测试或控制能力之外的情况时才使用错误句柄。
* 只有当两个或更多操作被作为一个单元执行时，才使用上下文处理。
现在回顾一下，有许多问题可以作为普遍性的方针：
* 避免冗余--不要设置那些默认状态下已经设置的属性。
* 限制函数调用的次数。
* 缩小代码的范围。
第五课.对你的ASP程序作负载测试
本文分为两大部分，我将介绍一些性能测试结果，帮助开发人员来确定某一特定举措是否不仅对将来的项目来说是值得的，并且能够对原来的项目进行更新。在第一部分我将回顾一些ASP开发的基础性问题。在第二部分，将涉及一些最优化ADO函数，并将它们的结果与调用VB COM对象执行相同ADO函数的ASP页面进行比较。这些结果很让人开眼界，甚至有些时候是很令人吃惊的。
在本文中，我们将回答以下问题：
* 将ASP生成的内容写入响应流中最有效的方法是什么？
* 是否应该开启缓冲器？
* 是否应该考虑向ASP代码中增加注释？
* 是否应该为页面明确地设置默认语言？
* 如果不需要，是否应该关闭Session 状态？
* 是否应该把脚本逻辑放在子程序和函数区中？
* 使用包含文件有什么影响？
* 执行错误处理时会施加什么样的负载？
* 设置一个上下文处理是否对性能有影响？
所有测试都是用Microsoft的Web应用程序重点工具(WAST)来进行的，这是一个免费的工具，可以在这里找到。我用WAST创建了一个简单的test 脚本，反复调用下面所描述的ASP页面测试（每个超过70，000次）。反应的时间基于平均最后字节总时间(TTLB), 也就是从最初请求的时间到工具从服务器接收最后一位数据的时间。我们的测试服务器是一个Pentium 166，内存为196MB，客户机为Pentium 450，内存为256MB。你也许会想这些机器的性能并不算很高级，但是不要忘了，我们并不是要测试服务器的容量，我们只是要测试服务器每次处理一个页面所用的时间。测试期间这些机器不做其它工作。WAST 测试脚本、测试报告以及所有的ASP测试页面都包含在ZIP文件中，你可以自己进行回顾和测试。
将ASP生成的内容写入响应流中最有效的方法是什么？
使用ASP的一个最主要原因是在服务器上生成动态内容。所以很明显，我们测试的起点是确定将动态内容发送到响应流中的最适合的方式。在多种选择中，有两个是最基本的：一是使用内联ASP标记，另一个是使用Response.Write 语句。
为测试这些选择，我们创建了一个简单的ASP页面，其中定义了一些变量，然后将它们的值插入表格中。虽然这个页面很简单也不是很实用，但它允许我们分离并测试一些单独的问题。
使用ASP内联标记
第一个测试包括使用内联ASP标记＜ %= x % ＞，其中x是一个已赋值的变量。到目前为止，这个方法是最容易执行的，并且它使页面的HTML部分保持一种易于阅读和维护的格式。
＜ % OPTION EXPLICIT
Dim FirstName
Dim LastName
Dim MiddleInitial
Dim Address
Dim City
Dim State
Dim PhoneNumber
Dim FaxNumber
Dim EMail
Dim BirthDate
FirstName = "John"
MiddleInitial = "Q"
LastName = "Public"
Address = "100 Main Street"
City = "New York"
State = "NY"
PhoneNumber = "1-212-555-1234"
FaxNumber = "1-212-555-1234"
EMail = "john@public.com"
BirthDate = "1/1/1950"
% ＞
＜ HTML ＞
＜ HEAD ＞
＜ TITLE ＞Response Test＜ / TITLE ＞
＜ /HEAD ＞
＜ BODY ＞
＜ H1 ＞Response Test＜ /H1 ＞
＜ TABLE ＞
＜ tr ＞＜ td ＞＜ b ＞First Name:＜ /b ＞＜ /td ＞＜ td ＞＜ %= FirstName % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Middle Initial:＜ /b ＞＜ /td ＞＜ td ＞＜ %= MiddleInitial % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Last Name:＜ /b ＞＜ /td ＞＜ td ＞＜ %= LastName % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Address:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Address % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞City:＜ /b ＞＜ /td ＞＜ td ＞＜ %= City % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞State:＜ /b ＞＜ /td ＞＜ td ＞＜ %= State % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Phone Number:＜ /b ＞＜ /td ＞＜ td ＞＜ %= PhoneNumber % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Fax Number:＜ /b ＞＜ /td ＞＜ td ＞＜ %= FaxNumber % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞EMail:＜ /b ＞＜ /td ＞＜ td ＞＜ %= EMail % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Birth Date:＜ /b ＞＜ /td ＞＜ td ＞＜ %= BirthDate % ＞＜ /td ＞＜ /tr ＞
＜ /TABLE ＞
＜ /BODY ＞
＜ /HTML ＞
/app1/response1.asp的完整代码
以前的最佳（反应速度） = 8.28 msec/page
在HTML的每一行使用Response.Write 语句
许多比较好的学习文档建议避免使用前面的那种方法。其主要理由是，在输出页面和处理页面施加反应时间的过程中，如果web 服务器不得不在发送纯HTML和处理脚本之间进行转换，就会发生一种被称为上下文转换的问题。大部分程序员一听到这里，他们的第一反应就是将原始的HTML的每一行都包装在Response.Write函数中。
…
Response.Write("＜ html ＞")
Response.Write("＜ head ＞")
Response.Write(" ＜ title ＞Response Test＜ /title ＞")
Response.Write("＜ /head ＞")
Response.Write("＜ body ＞")
Response.Write("＜ h1 ＞Response Test＜ /h1 ＞")
Response.Write("＜ table ＞")
Response.Write("＜ tr ＞＜ td ＞＜ b ＞First Name:＜ /b ＞＜ /td ＞＜ td ＞" & FirstName & "＜ /td ＞＜ /tr ＞")
Response.Write("＜ tr ＞＜ td ＞＜ b ＞Middle Initial:＜ /b ＞＜ /td ＞＜ td ＞" & MiddleInitial & "＜ /td ＞＜ /tr ＞")
…
/app1/response2.asp的片段
以前的最佳（反应速度） = 8.28 msec/page
反应时间 = 8.08 msec/page
差= -0.20 msec (减少 2.4%)
我们可以看到，使用这种方法与使用内联标记的方法相比在性能上获得的收益非常小，这也许是因为页面给服务器装载了一大堆小的函数调用。这种方法最大的缺点是，由于现在HTML都嵌入脚本中，所以脚本代码变得更加冗长，更加难以阅读和维护。
使用包装函数
当我们试图使用Response.Write 语句这种方法时，最令人灰心的发现可能就是Response.Write 函数不能在每行的结尾处放置一个CRLF 。因此，当你从浏览器中阅读源代码时，本来布置得非常好的HTML，现在成了没有结束的一行。我想，你的下一个发现可能会更令你恐怖：在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 msec/page
反应时间= 10.11 msec/page
差 = +2.03 msec (增加 25.1%)
当然，由于这种方法有效地使函数调用次数加倍，其对性能的影响也很明显，因此要不惜一切代价避免。具有讽刺意味的是CRLF也向反应流中为每行增加了2个字节，而这是浏览器不需要呈现到页面上的。格式化良好的HTML所做的一切就是让你的竞争者更容易阅读你的HTML源代码并理解你的设计。
将连续的Response.Write 连接到一个单独语句中
不考虑我们前面用包装函数进行的测试，下一个合乎逻辑的步骤就是从单独的Response.Write 语句中提取出所有的字符串，将它们连接到一个单独语句中，这样就减少了函数调用的次数，极大地提高了页面的性能。
…
Response.Write("＜ html ＞" & _
"＜ head ＞" & _
"＜ title ＞Response Test＜ /title ＞" & _
"＜ /head ＞" & _
"＜ body ＞" & _
"＜ h1 ＞Response Test＜ /h1 ＞" & _
"＜ table ＞" & _
"＜ tr ＞＜ td ＞＜ b ＞First Name:＜ /b ＞＜ /td ＞＜ td ＞" & FirstName & "＜ /td ＞＜ /tr ＞" & _
…
"＜ tr ＞＜ td ＞＜ b ＞Birth Date:＜ /b ＞＜ /td ＞＜ td ＞" & BirthDate & "＜ /td ＞＜ /tr ＞" & _
"＜ /table ＞" & _
"＜ /body ＞" & _
"＜ /html ＞")
/app1/response3.asp的片段
以前的最佳（反应速度）= 8.08 msec/page
反应时间 = 7.05 msec/page
差 = -1.03 msec (减少12.7%)
目前，这是最优化的配置。
将连续的Response.Write 连接到一个单独语句中，在每行结尾处增加一个CRLF
考虑到那些要求他们的源代码从浏览器中看要很纯粹的人，我用vbCRLF 常量在前面测试中每行的结尾处插入了一些回车，然后重新运行。
…
Response.Write("＜ html ＞" & vbCRLF & _
"＜ head ＞" & vbCRLF & _
" ＜ title ＞Response Test＜ /title ＞" & vbCRLF & _
"＜ /head ＞" & vbCRLF & _
…
/app1/response5.asp的片段
前面的最佳（反应速度）= 7.05 msec/page
反应时间= 7.63 msec/page
差 = +0.58 msec (增加 8.5%)
运行的结果在性能上有一点降低，这也许是由于额外的串联和增加的字符量。
回顾和观测
从前面有关ASP输出的测试中可以得出一些规则：
* 避免内联ASP的过多使用。
* 总是将连续Response.Write 语句连接进一个单独语句内。
* 永远不要在Response.Write 周围使用包装函数来附加CRLF。
* 如果必须格式化HTML输出，直接在Response.Write 语句内附加CRLF。
是否应该开启缓冲器？
通过脚本程序启动缓冲器
在ASP脚本的顶部包含Response.Buffer=True ，IIS就会将页面的内容缓存。
＜ % OPTION EXPLICIT
Response.Buffer = true
Dim FirstName
…
/app1/buffer__1.asp的片段
以前的最佳（反应时间）= 7.05 msec/page
反应时间 = 6.08 msec/page
差= -0.97 msec (降低13.7%)
性能得到了极大提高。但是等等，还能有更好的。
通过服务器配置启动缓冲器
虽然在IIS 5.0中缓冲器是被默认启动的，但是在IIS 4.0中还必须手动来启动它。这时要找到站点的Properties 对话框，在那里，从Home Directory 标签中选择配置按钮。然后在"App options"下选择"enable buffering" 。对于这个测试，Response.Buffer 语句从脚本中被移走了。
以前的最佳= 7.05 msec/page
反应时间 = 5.57 msec/page
差= -1.48 msec (降低 21.0%)
目前，这是我们所得到的最快反应了，比我们以前最好情况下的反应时间还要降低21%。从现在开始，我们以后的测试都要把这个反应时间作为基准值。
回顾及观测
缓冲器是提高性能的好方法，所以把缓冲器设置成服务器的默认值很有必要。如果因为某些原因，页面不能正确地使缓冲器运行，只需要Response.Buffer=False 命令即可。缓冲器的一个缺点是在整个页面处理完之前，用户从服务器看不到任何东西。因此，在复杂页面的处理期间，偶而调用一次Response.Flush 来更新用户是个好主意。
现在在我们的规则中又增加了一条：总是通过服务器设置开启缓冲器。
是否应该考虑向ASP代码中增加注释？
大部分HTML开发人员都知道包含HTML注释不是个好主意，首先会增加传输数据的规模，其次它们只是向别的开发人员提供有关你页面组织的信息。但是ASP页面上的注释又如何呢？它们从来不离开服务器，但也确实要增加页面的规模，因此必须用ASP进行分解。
在这次的测试中，我们增加20条注释，每条有80个字符，总共有1600个字符。
＜ % OPTION EXPLICIT
'-------------------------------------------------------------------------------
… 20 lines …
'-------------------------------------------------------------------------------
Dim FirstName
…
/app2/comment_1.asp片段
基准= 5.57 msec/page
反应时间= 5.58 msec/page
差 = +0.01 msec (增加 0.1%)
测试的结果是惊人的。虽然注释几乎相当于文件本身的两倍，但是它们的存在并没有给反应时间带来很大的影响。所以说我们可以遵循以下规则：
只要使用适度，ASP注释对性能的影响很小或根本没有影响。
是否应该为页面明确地设置默认语言？
IIS处理VBScript是默认的设置，但是我看到，在大多数例子中还是用＜ %@LANGUAGE=VBSCRIPT% ＞声明将语言明确地设置为VBScript 。我们的下一个测试将检验这个声明的存在对性能有什么影响。
＜ %@ LANGUAGE=VBSCRIPT % ＞
＜ % OPTION EXPLICIT
Dim FirstName
…
/app2/language1.asp片段。
基准值= 5.57 msec/page
反应时间= 5.64 msec/page
差= +0.07 msec (增加1.2%)
可以看到，包含了语言的声明对性能有一个轻微的影响。因此：
* 设置服务器的默认语言配置以与站点上使用的语言相匹配。
* 除非你使用非默认语言，不要设置语言声明。
如果不需要，是否应该关闭Session 状态？
避免使用IIS的Session上下文有许多理由，那些已经可以独立成为一篇文章。我们现在试图回答的问题是当页面不需要时，关闭Session上下文是否对性能提高有所帮助。从理论上讲应该是肯定的，因为这样一来就不需要用页面例示Session上下文了。
同缓冲器一样，Session状态也有两种配置方法：通过脚本和通过服务器设置。
通过脚本关闭Session上下文
对于这个测试，要关闭页面中的Session上下文，我增加一个Session状态声明。
＜ %@ ENABLESESSIONSTATE = FALSE % ＞
＜ % OPTION EXPLICIT
Dim FirstName
…
/app2/session_1.asp片段。
基准值= 5.57 msec/page
反应时间= 5.46 msec/page
差= -0.11 msec (降低2.0%)
只通过这样一个小小的努力就得到了不错的进步。现在看看第二部分。
通过服务器配置关闭Session 上下文
要在服务器上关闭Session 上下文，请到站点的Properties 对话框。在Home Directory 标签上选择Configuration 按钮。然后在"App options"下取消"enable session state" 的选择。我们在没有ENABLESESSIONSTATE 声明的情况下运行测试。
基准值 = 5.57 msec/page
反应时间= 5.14 msec/page
差= -0.43 msec (降低7.7%)
这是性能的又一个显著提高。所以，我们的规则应是：在不需要的情况下，总是在页面或应用程序的水平上关闭Session状态。
使用Option Explicit 会使性能有实质改变吗？
在一个ASP页面的顶部设置Option Explicit 以要求所有的变量在使用之前都要在页面上进行声明。这有两个原因。首先应用程序可以更快地处理变量的存取。其次，这样可以防止我们无意中错用变量的名字。在这个测试中我们移走Option Explicit 引用和变量的Dim 声明。
基准值 = 5.57 msec/page
反应时间= 6.12 msec/page
差 = +0.55 msec (9.8% 增加)、
尽管有一些代码行从页面中去掉了，反应时间却依然增加了。所以尽管使用Option explicit 有时候费时间，但是在性能上却有很显著的效果。因此我们又可以增加一条规则：在VBScript中总是使用Option explicit。
是否应该把脚本逻辑放在子程序和函数区？
用函数和子程序来组织和管理代码是一个很好的方法，特别是当一个代码区在页面中多次使用的情况。缺点是要在系统上增加一个做相同工作的额外函数调用。子程序和函数的另一个问题是变量的范围。从理论上说，在一个函数区内指定变量更有效。现在我们看看这两个方面如何发生作用。
将Response.Write 语句移入子程序
这个测试只是将Response.Write 语句移入一个子程序区内。
…
CALL writeTable()
SUB writeTable()
Response.Write("＜ html ＞" & _
"＜ head ＞" & _
…
"＜ tr ＞＜ td ＞＜ b ＞EMail:＜ /b ＞＜ /td ＞＜ td ＞" & EMail & "＜ /td ＞＜ /tr ＞" & _
"＜ tr ＞＜ td ＞＜ b ＞Birth Date:＜ /b ＞＜ /td ＞＜ td ＞" & BirthDate & "＜ /td ＞＜ /tr ＞" & _
"＜ /table ＞" & _
"＜ /body ＞" & _
"＜ /html ＞")
END SUB
/app2/function1.asp片段
基准值= 5.57 msec/page
反应时间= 6.02 msec/page
差 = +0.45 msec (8.1% 增加)
同预料中一样，子程序调用给页面带来了额外的负担。
将所有脚本移入子程序中
在这个测试中，Response.write 语句与变量声明都移入一个子程序区中。
＜ % OPTION EXPLICIT
CALL writeTable()
SUB writeTable()
Dim FirstName
…
Dim BirthDate
FirstName = "John"
…
BirthDate = "1/1/1950"
Response.Write("＜ html ＞" & _
"＜ head ＞" & _
" ＜ title ＞Response Test＜ /title ＞" & _
"＜ /head ＞" & _
"＜ body ＞" & _
"＜ h1 ＞Response Test＜ /h1 ＞" & _
"＜ table ＞" & _
"＜ tr ＞＜ td ＞＜ b ＞First Name:＜ /b ＞＜ /td ＞＜ td ＞" & FirstName & "＜ /td ＞＜ /tr ＞" & _
…
"＜ tr ＞＜ td ＞＜ b ＞Birth Date:＜ /b ＞＜ /td ＞＜ td ＞" & BirthDate & "＜ /td ＞＜ /tr ＞" & _
"＜ /table ＞" & _
"＜ /body ＞" & _
"＜ /html ＞")
END SUB
/app2/function2.asp片段
基准值= 5.57 msec/page
反应时间= 5.22 msec/page
差 = -0.35 msec (6.3% 降低)
非常有趣！尽管将变量移到函数范围内增加了额外的函数调用，但实际上却提高了性能。我们又可以增加以下规则：
* 在一个页面上，如果代码要使用一次以上，就将代码封入函数区。
* 适当时候，将变量声明移到函数范围内。
使用包含文件有什么影响？
ASP编程的一个重要功能就是包含来自其它页面的代码。通过这项功能，程序员可以在多个页面上共享函数，使代码更易于维护。缺点在于服务器必须从多个来源组装页面。以下是使用Include文件的两个测试。
使用内联代码的Include 文件
在这个测试中，有一小段代码被移到一个Include 文件中：
＜ % OPTION EXPLICIT
Dim FirstName
…
Dim BirthDate
FirstName = "John"
…
BirthDate = "1/1/1950"
% ＞
＜ !-- #include file="inc1.asp" -- ＞
/app2/include_1.asp片段
基准值 = 5.57 msec/page
反应时间= 5.93 msec/page
差 = +0.36 msec (6.5% 增加)
这不奇怪。使用Include 文件形成了负载。
在函数区使用Include 文件
在这里，代码都包装在一个Include 文件中的子程序里。Include 引用是在页面顶部进行的，在ASP脚本的适当位置调用子程序。
＜ % OPTION EXPLICIT
Dim FirstName
…
Dim BirthDate
FirstName = "John"
…
BirthDate = "1/1/1950"
CALL writeTable()
% ＞
＜ !-- #include file="inc2.asp" -- ＞
/app2/include_2.asp片段
基准值 = 5.57 msec/page
反应时间= 6.08 msec/page
差 =+0.51 msec (9.2% 增加)
这对性能造成的影响比functions调用还大。因此：只有当代码在页面之间共享时才使用Include 文件。
执行错误处理时会形成多大的负载？
对于所有真正的应用程序来说，错误处理都是必要的。这个测试中，通过调用On Error Resume Next函数来调用错误句柄。
＜ % OPTION EXPLICIT
On Error Resume Next
Dim FirstName
…
/app2/error_1.asp片段
基准值 = 5.57 msec/page
反应时间= 5.67 msec/page
差= 0.10 msec (1.8% 增加)
你可以看到，错误句柄带来了代价。我们可以提出以下建议：只有在会发生超出测试或控制能力之外的情况时才使用错误句柄。一个最基本的例子就是使用存取其它资源，如ADO或FileSystem 对象的COM对象。
设置一个上下文处理是否对性能有影响？
当错误发生时，在页面上设置一个上下文处理允许脚本进行反转操作。这是通过在页面上使用处理声明来设置的。
＜ %@ TRANSACTION = REQUIRED % ＞
＜ % OPTION EXPLICIT
Dim FirstName
…
/app2/transact1.asp片段
基准值 = 5.57 msec/page
反应时间= 13.39 msec/page
差 = +7.82 msec (140.4% 增加)
啊！这真实最具有戏剧性的结果。所以请留意以下规则：只有当两个或更多操作被作为一个单元执行时，才使用处理上下文。
结论
本文第一部分的重要之处在于许多小事情的累积。为了强调这个问题，我设置了最后一个测试，在其中进行了我们以前曾经测试过的看来无所谓但实际上有坏影响的所有操作。我包含了许多Response.Write 声明、关闭了缓冲器、设置了默认语言、去掉了Option Explicit 引用并初始化了错误句柄。
＜ %@ LANGUAGE=VBSCRIPT % ＞
＜ %
On Error Resume Next
FirstName = "John"
…
BirthDate = "1/1/1950"
Response.Write("＜ html ＞")
Response.Write("＜ head ＞")
Response.Write(" ＜ title ＞Response Test＜ /title ＞")
Response.Write("＜ /head ＞")
Response.Write("＜ body ＞")
Response.Write("＜ h1 ＞Response Test＜ /h1 ＞")
Response.Write("＜ table ＞")
Response.Write("＜ tr ＞＜ td ＞＜ b ＞First Name:＜ /b ＞＜ /td ＞＜ td ＞" &_
"FirstName & "＜ /td ＞＜ /tr ＞")
…
Response.Write("＜ tr ＞＜ td ＞＜ b ＞Birth Date:＜ /b ＞＜ /td ＞＜ td ＞" &_
" BirthDate & "＜ /td ＞＜ /tr ＞")
Response.Write("＜ /table ＞")
Response.Write("＜ /body ＞")
Response.Write("＜ /html ＞")
% ＞
/app2/final_1.asp片段
基准值 = 5.57 msec/page
反应时间 = 8.85 msec/page
差 = +3.28 msec (58.9% 增加)
听起来可能很明显，但是理解更重要，那就是我们放置在页面上的代码会对性能有影响。页面上的小变化有时会大大地增加反应时间。
规则概括
* 避免内联ASP的过多使用。
* 总是将连续Response.Write 语句连接进一个单独语句内。
* 永远不要在Response.Write 周围使用包装函数以附加CRLF。
* 如果必须格式化HTML输出，直接在Response.Write 语句内附加CRLF。
* 总是通过服务器设置开启缓冲器。
* 只要使用适度，ASP注释对性能的影响很小或根本没有影响。
* 设置服务器的默认语言配置以与站点上使用的语言相匹配。
* 除非你使用非默认语言，不要设置语言声明。
* 在VBScript中总是使用Option explicit 。
* 在不需要的情况下，总是在页面或应用程序的水平上关闭Session状态。
* 只有当代码在页面之间共享时才使用Include 文件。
* 在一个页面上，如果代码要使用一次以上，就将代码封入函数区。
* 适当时候，将变量声明移到函数范围内。
* 只有会发生超出测试或控制能力之外的情况时才使用错误句柄。
* 只有当两个或更多操作被作为一个单元执行时，才使用上下文处理。
现在回顾一下，有许多问题可以作为普遍性的方针：
* 避免冗余--不要设置那些默认状态下已经设置的属性。
* 限制函数调用的次数。
* 缩小代码的范围。
| 第四课.用数据绑定实现高效率动态网页 数据绑定（Data Binding）并不是一个新概念，IE 4.0就已对其给予了丰富的支持。但是，数据绑定并未受到应有的重视，许多开发者似乎更加愿意使用服务器端脚本（Server Script）的方法。然而实际上，无论是在动态网页的代码实现方面，还是在动态网页的工作效率方面，数据绑定的效率都比后者更高。 本文将介绍数据绑定的体系结构、工作原理及其实现方式，最后对这两种方法在编程工作量和网页效率等方面做出比较和结论。 首先让我们看一个简单的例子。某一网页显示仓库的当前库存情况，用户可自行选择数据的排序方式：按货物的名称、价格、库存量等排序。使用服务器端的技术，例如CGI、ISAPI，或者ASP等中间件，用户若需要N种排序方式，则应用程序脚本至少要向服务器提交N次数据请求。对于同样内容的数据，仅仅因为显示方式的不同，就要进行多次数据库操作，耗费大量的网络带宽。 另一个常见的例子是，大量数据需要分页显示时，每一次翻页都需要重新向服务器建立连接，递交查询请求，再定位数据。对这些类似问题，数据绑定都提供了高效的解决方案。 数据绑定的体系结构和工作原理 数据绑定体系结构包括四个组成部分：数据源对象（Data Source Object）、数据显示对象（Data Consumers）和两个代理器（Binding Agent与Table Reptition Agent）。数据源对象向网页提供数据，数据显示对象就是显示数据的HTML元素，代理器则用来保证前两者的工作同步。图1显示了这四个部分协同工作的原理。 如图1所示，数据源对象负责与后台数据库服务器通信，并将DB Server返回的数据以集合形式缓存在本地Cache。此后，对此数据集所做的任何操作，如排序、过滤、取子集等，都在本地Cache中进行，由代理器来负责数据源和显示该数据的HTML元素之间的通信和同步。  图1 数据绑定的这种工作方式，使得程序开发人员只要使用扩展HTML和可插入的数据源对象，就能使脚本的编程量达到最小。与传统的服务器端脚本生成的网页相比，数据只要一次下载到客户端后，对该数据所做的任何操作都不再需要额外的服务器请求，因此节省了网络带宽，提高了下载速度。 数据绑定的实现 本节将根据数据绑定的体系结构，分别介绍它的各个组成部分及其实现。 1. 数据源对象（Data Source Object） 实现数据绑定的第一步是：确定网页所要显示的数据，据此选择一个适合的数据源对象（DSO），再在网页中引用该DSO。数据绑定的灵活性首先表现在支持多种DSO，IE 4.0及以上版本支持下列DSO类型： ●Tabular Data Control（TDC）：这是一种简单的DSO，提供对格式化文本文件的访问。也就是说，TDC提供的数据来源是用指定分隔符来格式化的文本文件。 ●Remote Data Service（RDS）：RDS的前身是ADC（Access Data Control）。RDS通过OLE-DB或ODBC与数据库通信，获得数据。 ●JDBC DataSource Applet：它与RDS的不同之处在于数据库连接使用JDBC。 ●XML Data Source：扩展标记语言XML使用标准的方式来描述和交换结构化数据；XML的数据以开放的、基于文本的格式进行描述，并通过标准HTTP协议传输。XML本身的特性决定了它天生就是一种灵活强大的DSO。IE4.0使用JAVA APPLET来实现XML DSO；IE5.0支持Data Island，用户可以直接用标记定义的数据作为DSO。 ●MSHTML Data Source：除了使用外部的控件作为DSO外，开发人员还可以在HTML文档中定义数据集，并使用MSHTML本身作为数据源。 ●自定义类型DSO：除了以上明确定义的这五类DSO，IE还支持用户自定义类型的DSO，只要该DSO遵循IE 4/MSHTML Data Binding Interface即可。 DSO可以在设计时指定，也可以在运行时动态增加、修改和删除。 2.支持数据绑定的数据显示对象（Data Consumer） 可绑定的HTML元素共分为两大类：单值对象（Single-valued Consumer）和表对象（Tabular Consumer）。单值对象显示DSO提供的当前记录的某一个域，而表对象中的每行元素则分别对应一条记录中不同的域，并以此为模板重复显示数据集中的每条记录。数据显示对象既可以在设计时绑定到DSO，也可以在运行时动态绑定。 DSO和Data Consumer的动态特性，使得已经存在的元素绑定可以被修改；不但如此，DHTML对象模型（DHTML Object Modle）还支持运行时动态增加数据绑定元素和数据源对象，因此数据可以以异步方式下载到客户端。该特性使得开发人员可以减少网页内容的初始化下载时间，并可在一个页面上显示多个不同数据集的内容，交互式用户将由此获得高质量的服务。 支持数据绑定的HTML元素包括：A、Applet、Button、Div、Frame、Iframe、Img、Input(包括Checkbox、Hidden、Label、Password、Radio、Text等类型)、Label、Marquee、Select、Span和Textarea。其中,A、Button、Div、Img、Frame、Iframe、Lable、Marquee以及span支持只读功能的数据绑定；而Input(除Button类型外)、Select、Textarea、Object和Applet元素支持被绑定数据的Update功能。 3. 数据绑定支持的操作 对于只读类型的Data Consumer来说，数据绑定支持的操作就是显示DSO提供的数据集。具体功能包括： ● 动态增加和修改被绑定元素及DSO，如改变所显示的数据字段、对数据集进行过滤和排序等。 ● 动态改变数据集的显示方式，数据可以用HTML格式显示，也可用简单的Text格式显示。 ● 动态控制被显示数据的数量，即可动态改变分页显示时每页包含的记录数。 支持Update功能的Data Consumer不但支持上述功能，还支持记录的增加、修改和删除。也就是说，用户在交互页面上对数据的增加、修改和删除，将影响到显示该数据的元素所绑定到的数据集。为了方便对数据集的控制，数据绑定允许开发人员使用ADO（Active Data Objects）提供的所有方法和属性来维护DSO提供的数据集，包括Insert、Update、Delete及Navigation等操作。 数据绑定中一个非常重要的问题是，一定要清楚对Data Consumer所做的操作到底影响了哪些数据：是只对本地Cache中的数据起作用，还是已真正改变了后端数据库（这与DSO的类型有关）。TDC、XML Data Source以及MSHTML Data Source都只支持对Cache中的数据进行改变，而不支持将改变后的Cache中的数据提交到数据源所连接的后端数据库。而RDS和JDBC DataSource Applet都支持修改后端数据库的功能。 比较及结论 从表1可以看出，相对于服务器端脚本，数据绑定所生成的网页工作效率明显提高。但是使用该方法对程序员的要求较高，需要对Data Binding的深刻理解才能充分发挥将它的优良特性。复杂的工作就是高效率所必须付出的代价，在应用中，开发者应根据具体的需求和实际情况，选择适宜的方法或是将两者结合使用，以便获得最高的性能价格比。   |
第五课.对你的ASP程序作负载测试
J.D. Meier
September 27, 1999
内容
介绍
剧情
测试需求
介绍测试工具WAS
分析测试结果
影响表现和可测性的因素
模拟多用户
运行需要登录认证的测试
WAS的应用技巧
资源
介绍
当我们从传统的CS结构的应用程序转到当前流行的Web空间的程序时，我们发现我们在尝试跟上不断增长的可测性需求和性能要求。其中一个最大的挑战在于如何确定你的程序能最多支持多少个用户的访问。你如何面对这一挑战？设定清晰的性能目标并使用Web压力测试工具会是一个好的开始。
这篇文章将会介绍如何对你的ASP程序进行压力测试，同时将会介绍微软的压力测试工具- Web Application Stress test Tool (WAS).在接下来的一章，你将会学习到压力测试的基础，同时还会学到一些必要的技巧，通过这些学习，你将可以根据测试的结果更加有效的测试和修改你的程序。
剧情
假设你将要发布一个预期有1000用户使用的ASP程序。你清楚的知道你的程序至少能处理两个并发的用户的访问，因为你和你的伙伴能整天地点击这个ASP程序而不会出现任何的问题。你在怀疑到底两个用户能否精确地反映你的程序的受压能力。当然你可以使用标准的测试方法（发布你的程序，然后期待最好的结果出现），然而你还是决定预先测试你的程序的表现。这是一个好兆头！
测试需求
为了更好的测试你的ASP程序，你首先需要决定你的程序将来需要面对多大的压力。简单的说，压力或负载可以分解成以下数字：
· 最低用户数量。（这个程序的使用者的最低数量是多少？通常这个数值可以是每日或没周或每月的点击量—当然你也可以分解成一个更可控的数值—每小时访问量，）
· 并发用户的总量. (在最高峰时的糟糕状况是什么？作出相应的计划. 希望在有压力的情况下工作正常有效.)
· 请求高峰值. (每秒钟需要产生多少ASP页面? 这也许是在衡量一个ASP程序对用户请求作出反应的能力时的一个最重要的因素.)
为你的程序决定用户量和并发用户数通常是很困难的事情，而且是在你的程序在被实际使用之前。尤其是网络程序。即使是局域网程序也常常要面对用户增加的问题，所以准确的预计用户量将会是困难的。当你不知道怎么开始时，最好从基础的开始：
Internet需要考虑的问题：
· 分析你已有的IIS日志。这个数值会暗示出一些实际的几率
· 你的站点将会有多流行？流行的站点一天会有100万或更多的访问量。不会那么流行？那么假设一些不同的情况？假设你有1000以上的用户群？你能通过增加更多的硬件设备来解决扩展性问题吗？或者，你的程序的架构会成为瓶颈吗？
· 什么是最糟糕的情况？问一下你的朋友这些情况会发生吗？
Intranet需要考虑的问题：
· 同样地，分析你已有的IIS日志。
· 这个ASP程序是可以给每个人用的吗？在公司内部网有多少台机器？你的系统管理员可以告诉你有关网络高峰流量的东西吗？
· 这个程序有特定的用户对象吗？只是HR人力资源部？有多少个人力资源部的员工在使用？
· 最糟糕的情况是怎样的？
如果你不能提前决定适当的负载，那么确定你的程序的最高上限将是你最好的选择。如果被10个用户点击，你能在1秒内产生多少的ASP响应结果？100个呢？1000个呢？10000个呢？记录你的基准。当你从实际使用中得到你的流量日志显示你正在接近你的极限时，你将不仅会为你知道你当前的极限是什么，而且你会有时间准备解决的办法。
介绍测试工具WAS
虽然有很多的压力测试工具可供选择，但是在本文，我会主要集中介绍WAS（就是以前所谓的Homer），WAS是当前微软的标准网页压力测试工具。如果你已经对WebCat很熟悉了，你会激动的发现WAS可以很方便地导入现有的WebCat脚本。如果你以前用过InetMonitor，你会激动的发现WAS也是基于GUI的（对于很多使用命令行的WebCat的用户来说这将会是一个很好的附加特性）。另一个好处是它是免费的，我的一个好朋友常说，“如果是免费的，那么就是我的。”除了它的价格优势外，这个工具还提供了完整的功能，而且还在不断地升级更新中。Microsoft.com经常要使用它，所以他们会明白这个工具的重要性。
但是你不需要过多地理会我的话，只管自己去尝试。我在文章的结尾会提供一个列表，列出一些第三方的压力测试工具，你可以自己决定选什么工具。底线是你需要一个工具，能够把你的ASP程序放到负载下，在发布之前测试它。
开始使用WAS
我会教你怎样第一次使用这个工具来测试一个ASP页面。我也会介绍怎样使用署名登录的测试和多用户并发访问的测试，因为这些东西会使初学者一头雾水。
首先你需要下载和安装这个工具。你能从下面的链接中得到最新版本
http://www.microsoft.com/technet ... loads/webstres.asp. 在这个网站上还会有关于这个工具的入门指导，你可以随时回去看看。
以下是在安装时需要注意的几点：
· 不要把WAS安装在你的测试目标服务器上，安装在别的机器以确保得到准确的测试结果。
· 在安装WAS的机器上需要有ADO2。1以上的版本。如果oledb32.dll的版本不是2.10.3711或以上，ADO会被WAS自动安装。
· 在安装后你会有一个完整的安装日志，默认会在\Program Files\Microsoft Web Application Stress Tool\INSTALL.LOG.
· 如果你已经安装了旧版本的WAS，更新时会保留数据文件完好。WAS使用Access .mdb文件作为数据存储文件。WAS的初始.mdb包是WAS.mdb，可以在程序安装路径找到。
· WAS在注册表的HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WAS存储注册信息。
在运行我们新安装的WAS之前，我们创建一个简单的ASP脚本作为测试页面。创建一个新的叫做MyASPPage.asp 的ASP页面，然后插入以下脚本：
MyASPPage.asp
＜%@ Language=VBScript %＞
＜HTML＞
＜BODY＞
＜% CONST ForAppending = 8
set oFSO = server.CreateObject("Scripting.FileSystemObject")
'translate our virtual directory into a physical path
strFilePath = Server.MapPath(Request.ServerVariables("PATH_INFO"))
'grab the root of the virtual directory
strFilePath = left(strFilePath, (InstrRev(strFilePath, "\")))
strFilePath = strFilePath & "MyFile.txt"
'write out to the screen the full file path
Response.Write(strFilePath & "＜BR＞")
set oTS = oFSO.OpenTextFile(strFilePath,ForAppending, true)
oTS.writeline("Session Id: " & Session.SessionId & chr(32) & _
"Time: " & Cstr(now()))
%＞
＜/BODY＞
＜/HTML＞
这个ASP脚本将在一个文本文件中插入SessionId及其活动时间，这样我们可以方便地确认我们的ASP页面是否在正确的执行。一旦你熟悉了这个工具，你就可以指向你实际的ASP页面以作真正的测试。
在服务器的恰当的目录放置你的ASP页面以使它可以被匿名访问。我们在后面将会再试署名访问的测试，但是现在我们需要运行一个最基本的测试。用全路径URL浏览你的页面，包括你的服务器名。例如，一个完整的URL看起来像http://MyServer/MyVirtualDirectory/MyASPPage.asp。一旦你能成功地浏览你的ASP页面（务必检查MyFile.txt这个文件，这个文件会被程序写在虚拟目录的物理位置），你就可以运行WAS做实际的测试了。
当你第一次运行WAS时，将会出现下面的对话框：
Figure 1. Create a new script
虽然其他选项也很诱人，现在我们先选Manual 这项。将来你还可以从菜单的Scripts或在工具拦点取New Script图标来创建一个新的脚本。
欢迎来到脚本浏览界面。左手边的窗口以树型结构列出了你的脚本。在右手边的窗口里你可以修改你的脚本设置。
在左手边的窗口里的树状列表单击New Script可以激活脚本的浏览。在Server输入框输入你的服务器的名字。在Script Item的第一项，选择GET作为你的动作。在PATH输入你的ASP地址，以虚拟目录为开始符。见图Figure 2如下：
Figure 2. Enter the URL in the Path field
这时候，你可以点工具条上的Run Script箭头符号来执行你的脚本（务必确保你在左边的窗口点取了正确的脚本）。在产生一个概要的性能报告之前，这个脚本需要运行大概1分钟的时间。
分析测试结果
你可以点工具条上的Reports图标来看产生的报告。这将产生一个与Script tab相临的新的tab。报告被存储在一个大纲视图里。首先，在你的报告下面点Result Codes，这个将给你一个快速的印象，这次测试是否出现了什么问题。如果你看到的状态代码不是200，你也许需要调查一下出现了什么问题，通常的问题包括署名和不正确的URL路径。
点Overview，你将看到这个测试活动的一个简要快速的分析。从ASP的技术角度看，Request per Second，是一个需要深入分析的关键值。这个值越高越好。通常，如果你不能从使用报告和预算中决定出一个特定的目标，你可以让ASP 的Requests per Second值高于30，当然这个ASP是没有连数据库或使用其他组件的。因为可以预见，连接数据库将增加程序的负担。
虽然有Request per Second这个计数器默认包含在WAS里，你也许想增加其他的计数器。你可以在点了Perf Counters的图标后通过点Add Counter来增加其他的计数器。一个特别有用的计数器是ASP Requests Queued，这个计数器往往是在识别一个阻塞或长期驻留的页面或组件时的关键。关于分析ASP性能的资源有：
· Tuning Internet Information Server Performance
· Navigating the Maze of Settings for Web Server Performance Optimization
· IIS 4 Resource Kit
影响性能和可测量性的因素
服务器组成，数据库访问，和其他因素会大大降低ASP的Request per Second值。不同的配置选择也会起到不同的作用，在这里我要指出几个常出现的因素：
· 如果你在访问一个数据库，你是否有做连接池？关于连接池的详细资料请看Pooling in the Microsoft Data Access Components.
· 你是否在使用ASP Session 变量来存储状态？Session 变量会很快地影响可测性。它们需要服务器资源，而且如果你想增加机器以扩展性能，它们会起阻碍作用，因为Session是与特定机器相关连的。无状态是最大化可扩展性的方法。关于Session的替代请参考这篇文章: HowTo: Persisting Values without Session.
· 你是否在Session状态中存储有Visual Basic的组件？现在就去掉它们。Session中的Visual Basic对象会导致线程相关性而且会干扰打击IIS的线程池。这是一个复杂的主题，但是满足它的经验方法是：不要在Session中存储Single-threaded Apartment (STA) objects。如果你需要在Session中保留对象，它们应该被标记为”Both”，而且你需要自己聚合这些自由线程成为一个集合。Active Template Library (ATL)可以创建这样的怪物。
· 你的网络程序是被限定运行在它自己的内存空间的吗？实际上我们推荐进程保护。然而，如果你需要榨出一些额外的性能，在进程中运行你的网络程序将会节省一些交叉进程集合的开销。
· 当涉及Microsoft Transaction Server (MTS) components时，如果组件是作为服务器包而运行的而不是库包，那么将会有明显的性能区别。一个通常的建议是设置网络程序在它自己的内存空间中运行，然后在库包中运行MTS组件。
模拟多用户的情况
我会简要的介绍如何在WAS中模拟多用户请求的情况。你需要做两件事：
1. 在Settings面板改变Concurrent Connections。
2. 在Users创建用户，至少要创建多于你在Concurrent Connections里指定的用户数。
要改变并发用户数，点Settings图标。如果少于100个用户，你可以直接设置Stress Level，要模拟多于100个用户，你还须设置Stress Multiplier。基本公式为：用户数（线程数）= Stress Level * Stress Multiplier.如果要模拟1,000个用户，你可以设置Stress Level为100而Stress Multiplier为10。
如果你在没有设置足够的用户前尝试运行脚本，你将会得到一个警告。通过点Users图标可以修改你的用户数，你将在右边的窗口看到一个默认的Default组。双击Default组展开你的用户列表，如果你被允许匿名访问，那么你只要简单的填入新用户的代码然后点Create就可以了。
运行需要署名登录的测试
如果你想运行需要署名登录的页面，那么你需要创建合适的用户名和密码以便WAS在运行时可以使用。这同样是在Users设置的。你可以一开始就通过Remove All去掉当前的用户列表，然后添加你需要的用户，你也可以选择从文本文件导入用户名和密码。
但是无论如何，需要确保这些用户拥有有效的帐号，而且他们都可以访问IIS服务器。如果你使用的是BASIC基本认证用户帐号，你可以通过在你的浏览器提交证书来测试这个帐号，在文本文件写出Request.ServerVariables("AUTH_USER")这个值将会有很大的帮助作用。我们修改后的ASP代码将看起来是这样的：
oTS.writeline("Session Id: " & Session.SessionId & chr(32) & _
"Time: " & Cstr(now()) & "AUTH USER: " & chr(32) & Request.ServerVariables("AUTH_USER"))
使用WAS的技巧和提示
作为结束，我会提供一些技巧和提示，还有一些经验总结：
· 调整你的网站的日志文件的存储,因为这个文件将会快速的增大（见IIS文档）
· 通过设置注册表中的HKEY_LOCAL_MACHINE\Software\Microsoft\WAS\SessionTrace的DWORD为1，你可以以调试的方式追踪WAS的活动
· 如果你的WAS报告显示错误,务必检查Event Log，在工具外用浏览器浏览你的页面，然后检查服务器的日志：\WinNT\system32\LogFiles\W3SVCi
· 如果你的测试客户端机器的处理器使用率超过了%85，你也许需要添加更多的测试客户端
· 一些更有趣的话题会在WAS的文档里出现：Page Groups, Query Strings, Cookies, Web Application Stress Object Model和Active Server Page Client (这个会让你有能力通过Web远程控制测试客户端)
请注意这是个没有技术支持的工具，发送你的问题到webtool@microsoft.com。你可以在Web Application Stress Tool这个网沾上搜索一些常见的问题。你也可以对这个工具进行编程，在同样的网站上有对象模型的参考。
资源
要想获取更多的信息，WAS的网站上的tutorial是一个好去处。当然，请务必读一下随WAS附带的在线帮助—特别是一个叫Web stress testing overview的话题。
· WebHammer。一个由ServerObjects做的用于测试网络程序和服务器的工具
· LoadRunner .一个由Mercury Interactive做的压力测试工具,可以用来预见企业级程序的系统表现和性能
· Enterprise Monitor .由MediaHouse Software公司出品，用于监视，通报和恢复你的intranet 和 internet网络
· Extreme Soft's PerfMon。为Microsoft Transaction Server而做的工具，能从性能监视中提供直接的MTS监视。
J.D. Meier在美国东海岸出生并成长。自从留意了Greeley的建议以后，他就成为了一名开发支持工程师，专注于服务器端的组件和涉及MTS和ASP技术的Windows DNA应用。
第六课.最大限度优化你的Asp性能
September 27, 1999
内容
介绍
剧情
测试需求
介绍测试工具WAS
分析测试结果
影响表现和可测性的因素
模拟多用户
运行需要登录认证的测试
WAS的应用技巧
资源
介绍
当我们从传统的CS结构的应用程序转到当前流行的Web空间的程序时，我们发现我们在尝试跟上不断增长的可测性需求和性能要求。其中一个最大的挑战在于如何确定你的程序能最多支持多少个用户的访问。你如何面对这一挑战？设定清晰的性能目标并使用Web压力测试工具会是一个好的开始。
这篇文章将会介绍如何对你的ASP程序进行压力测试，同时将会介绍微软的压力测试工具- Web Application Stress test Tool (WAS).在接下来的一章，你将会学习到压力测试的基础，同时还会学到一些必要的技巧，通过这些学习，你将可以根据测试的结果更加有效的测试和修改你的程序。
剧情
假设你将要发布一个预期有1000用户使用的ASP程序。你清楚的知道你的程序至少能处理两个并发的用户的访问，因为你和你的伙伴能整天地点击这个ASP程序而不会出现任何的问题。你在怀疑到底两个用户能否精确地反映你的程序的受压能力。当然你可以使用标准的测试方法（发布你的程序，然后期待最好的结果出现），然而你还是决定预先测试你的程序的表现。这是一个好兆头！
测试需求
为了更好的测试你的ASP程序，你首先需要决定你的程序将来需要面对多大的压力。简单的说，压力或负载可以分解成以下数字：
· 最低用户数量。（这个程序的使用者的最低数量是多少？通常这个数值可以是每日或没周或每月的点击量—当然你也可以分解成一个更可控的数值—每小时访问量，）
· 并发用户的总量. (在最高峰时的糟糕状况是什么？作出相应的计划. 希望在有压力的情况下工作正常有效.)
· 请求高峰值. (每秒钟需要产生多少ASP页面? 这也许是在衡量一个ASP程序对用户请求作出反应的能力时的一个最重要的因素.)
为你的程序决定用户量和并发用户数通常是很困难的事情，而且是在你的程序在被实际使用之前。尤其是网络程序。即使是局域网程序也常常要面对用户增加的问题，所以准确的预计用户量将会是困难的。当你不知道怎么开始时，最好从基础的开始：
Internet需要考虑的问题：
· 分析你已有的IIS日志。这个数值会暗示出一些实际的几率
· 你的站点将会有多流行？流行的站点一天会有100万或更多的访问量。不会那么流行？那么假设一些不同的情况？假设你有1000以上的用户群？你能通过增加更多的硬件设备来解决扩展性问题吗？或者，你的程序的架构会成为瓶颈吗？
· 什么是最糟糕的情况？问一下你的朋友这些情况会发生吗？
Intranet需要考虑的问题：
· 同样地，分析你已有的IIS日志。
· 这个ASP程序是可以给每个人用的吗？在公司内部网有多少台机器？你的系统管理员可以告诉你有关网络高峰流量的东西吗？
· 这个程序有特定的用户对象吗？只是HR人力资源部？有多少个人力资源部的员工在使用？
· 最糟糕的情况是怎样的？
如果你不能提前决定适当的负载，那么确定你的程序的最高上限将是你最好的选择。如果被10个用户点击，你能在1秒内产生多少的ASP响应结果？100个呢？1000个呢？10000个呢？记录你的基准。当你从实际使用中得到你的流量日志显示你正在接近你的极限时，你将不仅会为你知道你当前的极限是什么，而且你会有时间准备解决的办法。
介绍测试工具WAS
虽然有很多的压力测试工具可供选择，但是在本文，我会主要集中介绍WAS（就是以前所谓的Homer），WAS是当前微软的标准网页压力测试工具。如果你已经对WebCat很熟悉了，你会激动的发现WAS可以很方便地导入现有的WebCat脚本。如果你以前用过InetMonitor，你会激动的发现WAS也是基于GUI的（对于很多使用命令行的WebCat的用户来说这将会是一个很好的附加特性）。另一个好处是它是免费的，我的一个好朋友常说，“如果是免费的，那么就是我的。”除了它的价格优势外，这个工具还提供了完整的功能，而且还在不断地升级更新中。Microsoft.com经常要使用它，所以他们会明白这个工具的重要性。
但是你不需要过多地理会我的话，只管自己去尝试。我在文章的结尾会提供一个列表，列出一些第三方的压力测试工具，你可以自己决定选什么工具。底线是你需要一个工具，能够把你的ASP程序放到负载下，在发布之前测试它。
开始使用WAS
我会教你怎样第一次使用这个工具来测试一个ASP页面。我也会介绍怎样使用署名登录的测试和多用户并发访问的测试，因为这些东西会使初学者一头雾水。
首先你需要下载和安装这个工具。你能从下面的链接中得到最新版本
http://www.microsoft.com/technet ... loads/webstres.asp. 在这个网站上还会有关于这个工具的入门指导，你可以随时回去看看。
以下是在安装时需要注意的几点：
· 不要把WAS安装在你的测试目标服务器上，安装在别的机器以确保得到准确的测试结果。
· 在安装WAS的机器上需要有ADO2。1以上的版本。如果oledb32.dll的版本不是2.10.3711或以上，ADO会被WAS自动安装。
· 在安装后你会有一个完整的安装日志，默认会在\Program Files\Microsoft Web Application Stress Tool\INSTALL.LOG.
· 如果你已经安装了旧版本的WAS，更新时会保留数据文件完好。WAS使用Access .mdb文件作为数据存储文件。WAS的初始.mdb包是WAS.mdb，可以在程序安装路径找到。
· WAS在注册表的HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WAS存储注册信息。
在运行我们新安装的WAS之前，我们创建一个简单的ASP脚本作为测试页面。创建一个新的叫做MyASPPage.asp 的ASP页面，然后插入以下脚本：
MyASPPage.asp
＜%@ Language=VBScript %＞
＜HTML＞
＜BODY＞
＜% CONST ForAppending = 8
set oFSO = server.CreateObject("Scripting.FileSystemObject")
'translate our virtual directory into a physical path
strFilePath = Server.MapPath(Request.ServerVariables("PATH_INFO"))
'grab the root of the virtual directory
strFilePath = left(strFilePath, (InstrRev(strFilePath, "\")))
strFilePath = strFilePath & "MyFile.txt"
'write out to the screen the full file path
Response.Write(strFilePath & "＜BR＞")
set oTS = oFSO.OpenTextFile(strFilePath,ForAppending, true)
oTS.writeline("Session Id: " & Session.SessionId & chr(32) & _
"Time: " & Cstr(now()))
%＞
＜/BODY＞
＜/HTML＞
这个ASP脚本将在一个文本文件中插入SessionId及其活动时间，这样我们可以方便地确认我们的ASP页面是否在正确的执行。一旦你熟悉了这个工具，你就可以指向你实际的ASP页面以作真正的测试。
在服务器的恰当的目录放置你的ASP页面以使它可以被匿名访问。我们在后面将会再试署名访问的测试，但是现在我们需要运行一个最基本的测试。用全路径URL浏览你的页面，包括你的服务器名。例如，一个完整的URL看起来像http://MyServer/MyVirtualDirectory/MyASPPage.asp。一旦你能成功地浏览你的ASP页面（务必检查MyFile.txt这个文件，这个文件会被程序写在虚拟目录的物理位置），你就可以运行WAS做实际的测试了。
当你第一次运行WAS时，将会出现下面的对话框：
Figure 1. Create a new script
虽然其他选项也很诱人，现在我们先选Manual 这项。将来你还可以从菜单的Scripts或在工具拦点取New Script图标来创建一个新的脚本。
欢迎来到脚本浏览界面。左手边的窗口以树型结构列出了你的脚本。在右手边的窗口里你可以修改你的脚本设置。
在左手边的窗口里的树状列表单击New Script可以激活脚本的浏览。在Server输入框输入你的服务器的名字。在Script Item的第一项，选择GET作为你的动作。在PATH输入你的ASP地址，以虚拟目录为开始符。见图Figure 2如下：
Figure 2. Enter the URL in the Path field
这时候，你可以点工具条上的Run Script箭头符号来执行你的脚本（务必确保你在左边的窗口点取了正确的脚本）。在产生一个概要的性能报告之前，这个脚本需要运行大概1分钟的时间。
分析测试结果
你可以点工具条上的Reports图标来看产生的报告。这将产生一个与Script tab相临的新的tab。报告被存储在一个大纲视图里。首先，在你的报告下面点Result Codes，这个将给你一个快速的印象，这次测试是否出现了什么问题。如果你看到的状态代码不是200，你也许需要调查一下出现了什么问题，通常的问题包括署名和不正确的URL路径。
点Overview，你将看到这个测试活动的一个简要快速的分析。从ASP的技术角度看，Request per Second，是一个需要深入分析的关键值。这个值越高越好。通常，如果你不能从使用报告和预算中决定出一个特定的目标，你可以让ASP 的Requests per Second值高于30，当然这个ASP是没有连数据库或使用其他组件的。因为可以预见，连接数据库将增加程序的负担。
虽然有Request per Second这个计数器默认包含在WAS里，你也许想增加其他的计数器。你可以在点了Perf Counters的图标后通过点Add Counter来增加其他的计数器。一个特别有用的计数器是ASP Requests Queued，这个计数器往往是在识别一个阻塞或长期驻留的页面或组件时的关键。关于分析ASP性能的资源有：
· Tuning Internet Information Server Performance
· Navigating the Maze of Settings for Web Server Performance Optimization
· IIS 4 Resource Kit
影响性能和可测量性的因素
服务器组成，数据库访问，和其他因素会大大降低ASP的Request per Second值。不同的配置选择也会起到不同的作用，在这里我要指出几个常出现的因素：
· 如果你在访问一个数据库，你是否有做连接池？关于连接池的详细资料请看Pooling in the Microsoft Data Access Components.
· 你是否在使用ASP Session 变量来存储状态？Session 变量会很快地影响可测性。它们需要服务器资源，而且如果你想增加机器以扩展性能，它们会起阻碍作用，因为Session是与特定机器相关连的。无状态是最大化可扩展性的方法。关于Session的替代请参考这篇文章: HowTo: Persisting Values without Session.
· 你是否在Session状态中存储有Visual Basic的组件？现在就去掉它们。Session中的Visual Basic对象会导致线程相关性而且会干扰打击IIS的线程池。这是一个复杂的主题，但是满足它的经验方法是：不要在Session中存储Single-threaded Apartment (STA) objects。如果你需要在Session中保留对象，它们应该被标记为”Both”，而且你需要自己聚合这些自由线程成为一个集合。Active Template Library (ATL)可以创建这样的怪物。
· 你的网络程序是被限定运行在它自己的内存空间的吗？实际上我们推荐进程保护。然而，如果你需要榨出一些额外的性能，在进程中运行你的网络程序将会节省一些交叉进程集合的开销。
· 当涉及Microsoft Transaction Server (MTS) components时，如果组件是作为服务器包而运行的而不是库包，那么将会有明显的性能区别。一个通常的建议是设置网络程序在它自己的内存空间中运行，然后在库包中运行MTS组件。
模拟多用户的情况
我会简要的介绍如何在WAS中模拟多用户请求的情况。你需要做两件事：
1. 在Settings面板改变Concurrent Connections。
2. 在Users创建用户，至少要创建多于你在Concurrent Connections里指定的用户数。
要改变并发用户数，点Settings图标。如果少于100个用户，你可以直接设置Stress Level，要模拟多于100个用户，你还须设置Stress Multiplier。基本公式为：用户数（线程数）= Stress Level * Stress Multiplier.如果要模拟1,000个用户，你可以设置Stress Level为100而Stress Multiplier为10。
如果你在没有设置足够的用户前尝试运行脚本，你将会得到一个警告。通过点Users图标可以修改你的用户数，你将在右边的窗口看到一个默认的Default组。双击Default组展开你的用户列表，如果你被允许匿名访问，那么你只要简单的填入新用户的代码然后点Create就可以了。
运行需要署名登录的测试
如果你想运行需要署名登录的页面，那么你需要创建合适的用户名和密码以便WAS在运行时可以使用。这同样是在Users设置的。你可以一开始就通过Remove All去掉当前的用户列表，然后添加你需要的用户，你也可以选择从文本文件导入用户名和密码。
但是无论如何，需要确保这些用户拥有有效的帐号，而且他们都可以访问IIS服务器。如果你使用的是BASIC基本认证用户帐号，你可以通过在你的浏览器提交证书来测试这个帐号，在文本文件写出Request.ServerVariables("AUTH_USER")这个值将会有很大的帮助作用。我们修改后的ASP代码将看起来是这样的：
oTS.writeline("Session Id: " & Session.SessionId & chr(32) & _
"Time: " & Cstr(now()) & "AUTH USER: " & chr(32) & Request.ServerVariables("AUTH_USER"))
使用WAS的技巧和提示
作为结束，我会提供一些技巧和提示，还有一些经验总结：
· 调整你的网站的日志文件的存储,因为这个文件将会快速的增大（见IIS文档）
· 通过设置注册表中的HKEY_LOCAL_MACHINE\Software\Microsoft\WAS\SessionTrace的DWORD为1，你可以以调试的方式追踪WAS的活动
· 如果你的WAS报告显示错误,务必检查Event Log，在工具外用浏览器浏览你的页面，然后检查服务器的日志：\WinNT\system32\LogFiles\W3SVCi
· 如果你的测试客户端机器的处理器使用率超过了%85，你也许需要添加更多的测试客户端
· 一些更有趣的话题会在WAS的文档里出现：Page Groups, Query Strings, Cookies, Web Application Stress Object Model和Active Server Page Client (这个会让你有能力通过Web远程控制测试客户端)
请注意这是个没有技术支持的工具，发送你的问题到webtool@microsoft.com。你可以在Web Application Stress Tool这个网沾上搜索一些常见的问题。你也可以对这个工具进行编程，在同样的网站上有对象模型的参考。
资源
要想获取更多的信息，WAS的网站上的tutorial是一个好去处。当然，请务必读一下随WAS附带的在线帮助—特别是一个叫Web stress testing overview的话题。
· WebHammer。一个由ServerObjects做的用于测试网络程序和服务器的工具
· LoadRunner .一个由Mercury Interactive做的压力测试工具,可以用来预见企业级程序的系统表现和性能
· Enterprise Monitor .由MediaHouse Software公司出品，用于监视，通报和恢复你的intranet 和 internet网络
· Extreme Soft's PerfMon。为Microsoft Transaction Server而做的工具，能从性能监视中提供直接的MTS监视。
J.D. Meier在美国东海岸出生并成长。自从留意了Greeley的建议以后，他就成为了一名开发支持工程师，专注于服务器端的组件和涉及MTS和ASP技术的Windows DNA应用。
第六课.最大限度优化你的Asp性能
ASP 能快速执行你的动态网页，但你还可以通过紧缩代码和数据库连接以使它们执行更快。这是一篇关于怎样精简代码和Asp 特征以获得最快执行速度的详细文章。对于一个急燥的用户来说，任何在按下用户按钮到结果出现在它们的屏幕之间的延迟可能意味着它们会转到浏览其它的站点？假如你的是商业站点，这有可能意味着失去潜在的销售。
我们没有任何办法控制用户的带宽，但我们的确能通过优化Asp 站点来获得最佳的性能。大部分潜在性能的提升是通过系统改变而不是紧缩代码，一个不合适的想法是，一旦遇到系统效率问题，就向系统管理者提意见要其升级系统。
首先，哪个因素可能影响Asp的性能？很不幸，有很多因素？下面这些只是其中的一部分：
可用带宽
服务器上的处理器和其它硬件的速度
在服务器上运行的其它程序(比如象那些OpenGL屏幕保护程序！)
数据库连接模式，连接池，数据库系统本身(比如Oracle优于Sql Server，Sql server优于Access)
所使用的语言
存储过程优于行式Sql语句
使用编译组件而不是VB或JavaScript，好的Asp编程经验，比如错误处理等
一些以上的因素可能已经被有IIS 知识经验的开发者普遍留意到了，但其它的可能对于他们来说是十分复杂的问题。在这篇文章里， 将试着解释所有影响Asp性能的每个因素，让我们看一看那些在我们刮胡子的几毫秒内就能做到的主要事情。
ASP脚本大小
你是脚本页(还有其它页面)是不是比必须的长度要长？这是一开始执行就会降低Asp 性能的东西。ASP 脚本在用来获取信息和格式化输出的时候是十分有用的，但脚本也是逐行解释执行，所以你的脚本越长，执行它的时间也就越长。
如果你的脚本很庞大，怎么做才能减少脚本的长度呢？这里有几点建议：
你可以将它们转换成服务器端组件，也就是说，做成VB动态链接库DLL或者通过先进的Windows编程语言或适当的COM 接口语言将它转换成未编译组件？并且在服务器端注册它们。有关的快速指南可以在
http://www.webdevelopersjournal.com/articles/activex_for_asp.html
找到。对一个写得好的ActiveX 组件进行编译不但能大幅度提高性能，还可以保护你的软件(脚本)，尤其当你将你的Asp站点发布在第三方主机上的时候。
因为脚本是逐行解释执行的，所以剔除多余的脚本或建立更高效率的脚本能够改进性能。如果你在单个Asp 文件中有数百行的代码，可能这样做你能很好地划分使用者，买卖和数据服务。事实上，如果你这样做，可能会找出一些冗余的代码：如果你需要输出几个表格，你可以编写一个通用函数来输出一个表格，只是多次调用它。
在讲述Asp 脚本的大小问题的时候，不得不提及包含文件的大小。当你使用一个包含文件的时候，整个包含文件被装入，当包含文件被包含的时候，相当于在Asp 文件本身写下那部分代码。因此，如果你在一个冗长的包含文件里定义了很多通用的方法和定义，要明白到在你包含该文件的时候，不管你要不要用到里面的每个方法和定义，它都是被整个装入的。ASP 缓存全部的展开代码，这会降低查找效率在这种情况下，包含文件必须被分割成更小的，模块化的文件。也要明白到包含文件被服务器视为单独的页面请求，使用太多的包含文件会影响下载时间。
＜!-- #include file="Header.asp" --＞
＜!-- #include file="Footer.asp" --＞
＜SCRIPT language="vbscript" runat="server"＞
Sub Main()
WriteHeader
WriteBody
WriteFooter
End Sub
Sub WriteBody()
...
End Sub
Main?'调用过程Main
＜/SCRIPT＞
假如你的脚本冗长的话，请使用Response.IsClientConnected。这意味着在客户端不再连接到服务器的时候，你的服务器CPU能避免循环等待。
＜%
'检查客户端是否仍在连接
If Not Response.IsClientConnected Then
'仍然连接着，处理程序
Else
'断开
End If
%＞
Interspersing ASP and HTML
每个人都这样做？当我们输出表格的时候，我们会在ASP 和HTML代码间转换，而这是一个不好的习惯。例如：
＜HTML＞
＜BODY＞
＜%
Set MyConn = Server.CreateObject("ADODB.Connection")
MdbFilePath = Server.MapPath("sample.mdb")
MyConn.Open "Driver={Microsoft Access Driver (*.mdb)}; DBQ=" & MdbFilePath & ";"
SQL_query = "SELECT * FROM Friends"
Set RS = MyConn.Execute(SQL_query)
WHILE NOT RS.EOF
%＞
＜LI＞＜%=RS("Name")%＞: ＜A HREF=""＞Homepage＜/A＞
＜%
RS.MoveNext
WEND
%＞
＜/BODY＞
＜/HTML＞
另一个普遍的例子是使用IF语句的时候：
＜%
If Not Session("DBOpen") Then
%＞
＜H1＞Database not connected＜/H1＞
＜%
Else
%＞
＜H1＞Database open＜/H1＞
＜%
End If
%＞
在这些情况下，脚本性能能通过将服务器端脚本写到一起来，而用Response.write产生Html代码来提高性能。比如：
＜%
If not Session ("DBOpen") Then
Response.Write "＜H1＞Database not connected＜/H1＞"
Else
Response.Write "＜H1＞Database open＜/H1＞"
End If
%＞
在大的脚本和很多脚本的情况下，你将能看到性能的提高。注意这里尽量避免了使用＜%标记，这样就能提高性能，ASP不需在执行脚本的时候计算字符的Ascii码。
Session状态
无庸置疑地，在Asp中能够通过Session维持某个状态的能力是十分强大的特色。然而，它会影响你的性能。明显地，你的站点的可伸缩性性变成了另一个问题，如果限制Session的使用的话。然而，session会为每个用户消耗服务器资源。
如果你不使用session 变量，或事实上你不必使用？使用隐藏表单域，在数据库中保存数据，查询字符串是不是其中的窍门？所以你应该禁止Session状态。你可以使用下面的声明禁止使用session：
@EnableSessionState = False
这样，ASP将不再检查session信息。
如果你不得不依赖于session状态，应该避免在session对象中存放大量的数据。IIS中的session在客户端的HTTP cookie可用的时候就会保持，导致被session占用的内存在session 终止或超时前一直被占用。这样，如果很多用户同时使用你的程序的时候，你的服务器资源可能会耗尽。
数据库访问
数据库访问是必须的麻烦？访问数据库将会激烈地减慢你的程序，但很显然，如果没有数据库，很多站点将变得毫无价值可言。但通过存储过程访问数据库来代替使用嵌入式Sql 语句，你可以提升潜在的性能。通过使用存储过程和ActiveX Data Objects (ADO)，它们亦同样拥有良好的灵活性。尽可能从存储过程来输出数据。
确认你的数据库具有索引，因为这样能直接提高你的程序的效率。同样，尽量在你的数据库服务器运行更新统计(Update Statistics) 以帮助追踪你的数据分发，这样，你的数据库就能够基于这些信息来改造查询执行。注意一些数据库比如MS Access，是不是真正能在企业级程序中接受？SQL Sever 7.0或者Oracle是一个更好的赌注。
让SQL象它被设计的那样工作，它能count(统计)，连接(join)，排序(sort)和group 数据。当你能够写出一个查询语句来做这些东西的时候，就不要自己用其它语言来实现。
下面是一个统计所有列的最简单的语法：
SELECT count(*) FROM publishers WHERE state='NY'
如果你统计一个指定的列，你必须使用group by语句来分组该列，否则它不会工作：
SELECT count(city),city FROM publishers GROUP BY city
分类返回的数据：
SELECT * FROM TableName WHERE FieldName＞50 OR FieldName＜100 ORDER BY FieldName2, Field Name3
使用Odbc还是文件DSN连接数据库？使用快速的OLEDB Provider技术连接你的数据库而不是使用DSN连接。不再需要恳求你的ISP(或数据库管理员/网管)为你建立一个系统DSN，当你移走Web文件的时候，亦不需要改变配置。
OLEDB 介于ODBC层和应用程序之间。在你的ASP 页面中，ADO介于ODEDB之上的“应用程序”。你的ADO调用首先被送到OLEDB，接着被送到ODBC层。然而，你可以直接连接到OLEDB 层，并且如果你这样做的话，你就能看到服务器端性能的提高。然而，怎样直接连接到OLEDB？
如果你使用SQLServer 7，使用下面的连接代码连接数据库：
strConnString = "DSN='';DRIVER={SQL SERVER};" & _
"UID=myuid;PWD=mypwd;" & _
"DATABASE=MyDb;SERVER=MyServer;"
最重要的参数是DRIVER=部分。如果你要绕过ODBC而使用通过使用OLEDB 连接SQL Server(这是更快的连接)，请使用下面的语法：
strConnString ="Provider=SQLOLEDB.1;Password=mypassword;" & _
"Persist Security Info=True;User ID=myuid;" & _
"Initial Catalog=mydbname;" & _
"Data Source=myserver;Connect Timeout=15"
有什么不对的地方吗？
现在你可能会觉得有点奇怪：我们在这个新的连接方法中的要点是什么呢？为什么不使用标准DSN-less/System DSN途径？呵，根据Wrox 在他的著作《ADO 2.0 Programmer's Reference》中测试的结果表明，如果你使用OLEDB连接和DSN或者DSN-less连接方法比较，你会发现有下面的改进：
性能对比：
SQL Access
OLEDBDSNOLEDBDSN
连接时间：18?82?连接时间：62?99
查询1,000条记录时间：29005400查询1,000条记录时间： 100950
注释：这个结果在Wrox的《ADO 2.0 Programmer's Reference》一书的第232和233页可以查到。时间的单位是毫秒，查询1,000记录时间是通过服务器端游标计算出来的(当使用客户端游标的时候，OLEDB与DSN记录集的性能之间的差别不大)。
ASP译码问题：
尽可能在客户端确认用户输入来减少HTTP来回请求的数量。如果浏览器有支持JavaScript或其它脚本的能力，使用它们的力量以释放更多的服务器资源。
下面的VBScript运行于客户端浏览器，在提交到你的服务器之前，用来验证用户信息：
＜SCRIPT LANGUAGE="VBScript"＞
＜!--
Sub btnEnter_OnClick
Dim TheForm
Set TheForm = Document.MyForm
If IsNumeric(TheForm.Age.Value) Then
TheForm.submit
Else
Msgbox "Please enter a numerical age."
End if
End Sub
//--＞
＜/SCRIPT＞
＜FORMmethod="POST" name=MyFormaction="myfile.asp"＞? Name: ＜INPUT typr="text" name="Name"＞
Age: ＜INPUT type="text" name="Age"＞
＜INPUT type="button" name="btnEnter"value="Enter"＞
＜/FORM＞
使用局部变量，避免使用全局变量。局部变量比全局变量更快地被Asp 脚本引擎存取，因为不需搜索整个名称域。避免改变数组定义。在第一次初始化的时候就简单分配足够的大小效率更高。在这种情况下，你可能会浪费一些内存，但你获得了速度的优势。在服务器负载重的时候这个技术是显然易见有效的。
如果你需要引用不一定要用到的对象，那么最好使用＜OBJECT＞标记而不是用 Server.CreateObject方法。 使用Server.CreateObject引起对象立即被建立，反之，＜OBJECT＞标记则不会这样立即建立对象如果使用＜object＞定义后不使用该对象，你不会浪费资源。
例如：下面的例子是一个使用＜OBJECT＞标记建立一个application-scope广告轮 Ad Rotator对象实
例：
＜OBJECT runat=server scope=Application id=MyAds progid="MSWC.AdRotator"＞
＜/OBJECT＞
在存储该Ad Rotator对象进Application后，你可以在任何程序的页面中用下面的语法访问该对象
＜%=MyAds.GetAdvertisement("CustomerAds.txt") %＞
打开'Option Explicit'开关。在VB和VBScript 中，你可以在没有显式声明的情况下使用变量。但打开这个选项可以鉴别用定义变量，这样可以很好地书写变量，并能帮助提高性能。未定义的局部变量会变慢，因为在建立它之前，名称空间必须被搜遍后才知道变量是否存在。摆脱它，使每个变量清楚地定义(先定义后使用)。
这是一个好习惯，it may trap typos, 这样更快。
除非你真正需要使用，否而不要使用Server.MapPath方法。如果你知道真实路径就使用真实路径。使用MapPath需要IIS找回现时服务器路径，这意味着得向服务器发一个特殊的请求，也就意味着降低了性能。另一个方法是将路径存放到局部变量中，在需要的时候使用，这样就不需要服务器多次查找。
检查你自己是怎么做的
你可以通过工具来测量你的系统性能，比如系统性能监视器，NetMon和PerfMon。测试web性能可以用WCAT (Web Capacity Analysis Tool)。使用WCAT，你可以测试你的IIS服务器和网络配置响应各种各样的客户请求，数据或HTML页面的能力。这些测试结果能够被用来作为优化你的服务器和网络配置的指导。WCAT是专门设计用来估计Windows 2000中的因特网服务(或Windows NT)和IIS 能响应的客户工作量
(仿真)。为了得到更多的信息，请参阅IIS Resource Kit(资源工具包)。那里也有冗长的WCAT用户指南在MSDN在线Web sorkshop站点里面有一个下载链接。如果你认真对待你的Asp 性能的话，务必取得该工具。
力求最优化应用程序性能，你的web 应用程序会运行更加顺畅。如果不是真正需要，就不要影响服务器的性能。
摘要：
上面介绍了有关ASP性能的资料，有很多因素影响Asp的性能，这里只讨论了其中的一部分。作为最终的想法，不要认为你能够处理好所有的因素，你的ASP 性能还是有必要提高的。你发布的每个应用程序必须个别进行考虑，所有以上的技巧并不是适合每个Asp程序。
This page is over.
由软件使用主页整理创作，如要引用，请指明出处，多谢
第七课.ASP提速技巧
我们没有任何办法控制用户的带宽，但我们的确能通过优化Asp 站点来获得最佳的性能。大部分潜在性能的提升是通过系统改变而不是紧缩代码，一个不合适的想法是，一旦遇到系统效率问题，就向系统管理者提意见要其升级系统。
首先，哪个因素可能影响Asp的性能？很不幸，有很多因素？下面这些只是其中的一部分：
可用带宽
服务器上的处理器和其它硬件的速度
在服务器上运行的其它程序(比如象那些OpenGL屏幕保护程序！)
数据库连接模式，连接池，数据库系统本身(比如Oracle优于Sql Server，Sql server优于Access)
所使用的语言
存储过程优于行式Sql语句
使用编译组件而不是VB或JavaScript，好的Asp编程经验，比如错误处理等
一些以上的因素可能已经被有IIS 知识经验的开发者普遍留意到了，但其它的可能对于他们来说是十分复杂的问题。在这篇文章里， 将试着解释所有影响Asp性能的每个因素，让我们看一看那些在我们刮胡子的几毫秒内就能做到的主要事情。
ASP脚本大小
你是脚本页(还有其它页面)是不是比必须的长度要长？这是一开始执行就会降低Asp 性能的东西。ASP 脚本在用来获取信息和格式化输出的时候是十分有用的，但脚本也是逐行解释执行，所以你的脚本越长，执行它的时间也就越长。
如果你的脚本很庞大，怎么做才能减少脚本的长度呢？这里有几点建议：
你可以将它们转换成服务器端组件，也就是说，做成VB动态链接库DLL或者通过先进的Windows编程语言或适当的COM 接口语言将它转换成未编译组件？并且在服务器端注册它们。有关的快速指南可以在
http://www.webdevelopersjournal.com/articles/activex_for_asp.html
找到。对一个写得好的ActiveX 组件进行编译不但能大幅度提高性能，还可以保护你的软件(脚本)，尤其当你将你的Asp站点发布在第三方主机上的时候。
因为脚本是逐行解释执行的，所以剔除多余的脚本或建立更高效率的脚本能够改进性能。如果你在单个Asp 文件中有数百行的代码，可能这样做你能很好地划分使用者，买卖和数据服务。事实上，如果你这样做，可能会找出一些冗余的代码：如果你需要输出几个表格，你可以编写一个通用函数来输出一个表格，只是多次调用它。
在讲述Asp 脚本的大小问题的时候，不得不提及包含文件的大小。当你使用一个包含文件的时候，整个包含文件被装入，当包含文件被包含的时候，相当于在Asp 文件本身写下那部分代码。因此，如果你在一个冗长的包含文件里定义了很多通用的方法和定义，要明白到在你包含该文件的时候，不管你要不要用到里面的每个方法和定义，它都是被整个装入的。ASP 缓存全部的展开代码，这会降低查找效率在这种情况下，包含文件必须被分割成更小的，模块化的文件。也要明白到包含文件被服务器视为单独的页面请求，使用太多的包含文件会影响下载时间。
＜!-- #include file="Header.asp" --＞
＜!-- #include file="Footer.asp" --＞
＜SCRIPT language="vbscript" runat="server"＞
Sub Main()
WriteHeader
WriteBody
WriteFooter
End Sub
Sub WriteBody()
...
End Sub
Main?'调用过程Main
＜/SCRIPT＞
假如你的脚本冗长的话，请使用Response.IsClientConnected。这意味着在客户端不再连接到服务器的时候，你的服务器CPU能避免循环等待。
＜%
'检查客户端是否仍在连接
If Not Response.IsClientConnected Then
'仍然连接着，处理程序
Else
'断开
End If
%＞
Interspersing ASP and HTML
每个人都这样做？当我们输出表格的时候，我们会在ASP 和HTML代码间转换，而这是一个不好的习惯。例如：
＜HTML＞
＜BODY＞
＜%
Set MyConn = Server.CreateObject("ADODB.Connection")
MdbFilePath = Server.MapPath("sample.mdb")
MyConn.Open "Driver={Microsoft Access Driver (*.mdb)}; DBQ=" & MdbFilePath & ";"
SQL_query = "SELECT * FROM Friends"
Set RS = MyConn.Execute(SQL_query)
WHILE NOT RS.EOF
%＞
＜LI＞＜%=RS("Name")%＞: ＜A HREF=""＞Homepage＜/A＞
＜%
RS.MoveNext
WEND
%＞
＜/BODY＞
＜/HTML＞
另一个普遍的例子是使用IF语句的时候：
＜%
If Not Session("DBOpen") Then
%＞
＜H1＞Database not connected＜/H1＞
＜%
Else
%＞
＜H1＞Database open＜/H1＞
＜%
End If
%＞
在这些情况下，脚本性能能通过将服务器端脚本写到一起来，而用Response.write产生Html代码来提高性能。比如：
＜%
If not Session ("DBOpen") Then
Response.Write "＜H1＞Database not connected＜/H1＞"
Else
Response.Write "＜H1＞Database open＜/H1＞"
End If
%＞
在大的脚本和很多脚本的情况下，你将能看到性能的提高。注意这里尽量避免了使用＜%标记，这样就能提高性能，ASP不需在执行脚本的时候计算字符的Ascii码。
Session状态
无庸置疑地，在Asp中能够通过Session维持某个状态的能力是十分强大的特色。然而，它会影响你的性能。明显地，你的站点的可伸缩性性变成了另一个问题，如果限制Session的使用的话。然而，session会为每个用户消耗服务器资源。
如果你不使用session 变量，或事实上你不必使用？使用隐藏表单域，在数据库中保存数据，查询字符串是不是其中的窍门？所以你应该禁止Session状态。你可以使用下面的声明禁止使用session：
@EnableSessionState = False
这样，ASP将不再检查session信息。
如果你不得不依赖于session状态，应该避免在session对象中存放大量的数据。IIS中的session在客户端的HTTP cookie可用的时候就会保持，导致被session占用的内存在session 终止或超时前一直被占用。这样，如果很多用户同时使用你的程序的时候，你的服务器资源可能会耗尽。
数据库访问
数据库访问是必须的麻烦？访问数据库将会激烈地减慢你的程序，但很显然，如果没有数据库，很多站点将变得毫无价值可言。但通过存储过程访问数据库来代替使用嵌入式Sql 语句，你可以提升潜在的性能。通过使用存储过程和ActiveX Data Objects (ADO)，它们亦同样拥有良好的灵活性。尽可能从存储过程来输出数据。
确认你的数据库具有索引，因为这样能直接提高你的程序的效率。同样，尽量在你的数据库服务器运行更新统计(Update Statistics) 以帮助追踪你的数据分发，这样，你的数据库就能够基于这些信息来改造查询执行。注意一些数据库比如MS Access，是不是真正能在企业级程序中接受？SQL Sever 7.0或者Oracle是一个更好的赌注。
让SQL象它被设计的那样工作，它能count(统计)，连接(join)，排序(sort)和group 数据。当你能够写出一个查询语句来做这些东西的时候，就不要自己用其它语言来实现。
下面是一个统计所有列的最简单的语法：
SELECT count(*) FROM publishers WHERE state='NY'
如果你统计一个指定的列，你必须使用group by语句来分组该列，否则它不会工作：
SELECT count(city),city FROM publishers GROUP BY city
分类返回的数据：
SELECT * FROM TableName WHERE FieldName＞50 OR FieldName＜100 ORDER BY FieldName2, Field Name3
使用Odbc还是文件DSN连接数据库？使用快速的OLEDB Provider技术连接你的数据库而不是使用DSN连接。不再需要恳求你的ISP(或数据库管理员/网管)为你建立一个系统DSN，当你移走Web文件的时候，亦不需要改变配置。
OLEDB 介于ODBC层和应用程序之间。在你的ASP 页面中，ADO介于ODEDB之上的“应用程序”。你的ADO调用首先被送到OLEDB，接着被送到ODBC层。然而，你可以直接连接到OLEDB 层，并且如果你这样做的话，你就能看到服务器端性能的提高。然而，怎样直接连接到OLEDB？
如果你使用SQLServer 7，使用下面的连接代码连接数据库：
strConnString = "DSN='';DRIVER={SQL SERVER};" & _
"UID=myuid;PWD=mypwd;" & _
"DATABASE=MyDb;SERVER=MyServer;"
最重要的参数是DRIVER=部分。如果你要绕过ODBC而使用通过使用OLEDB 连接SQL Server(这是更快的连接)，请使用下面的语法：
strConnString ="Provider=SQLOLEDB.1;Password=mypassword;" & _
"Persist Security Info=True;User ID=myuid;" & _
"Initial Catalog=mydbname;" & _
"Data Source=myserver;Connect Timeout=15"
有什么不对的地方吗？
现在你可能会觉得有点奇怪：我们在这个新的连接方法中的要点是什么呢？为什么不使用标准DSN-less/System DSN途径？呵，根据Wrox 在他的著作《ADO 2.0 Programmer's Reference》中测试的结果表明，如果你使用OLEDB连接和DSN或者DSN-less连接方法比较，你会发现有下面的改进：
性能对比：
SQL Access
OLEDBDSNOLEDBDSN
连接时间：18?82?连接时间：62?99
查询1,000条记录时间：29005400查询1,000条记录时间： 100950
注释：这个结果在Wrox的《ADO 2.0 Programmer's Reference》一书的第232和233页可以查到。时间的单位是毫秒，查询1,000记录时间是通过服务器端游标计算出来的(当使用客户端游标的时候，OLEDB与DSN记录集的性能之间的差别不大)。
ASP译码问题：
尽可能在客户端确认用户输入来减少HTTP来回请求的数量。如果浏览器有支持JavaScript或其它脚本的能力，使用它们的力量以释放更多的服务器资源。
下面的VBScript运行于客户端浏览器，在提交到你的服务器之前，用来验证用户信息：
＜SCRIPT LANGUAGE="VBScript"＞
＜!--
Sub btnEnter_OnClick
Dim TheForm
Set TheForm = Document.MyForm
If IsNumeric(TheForm.Age.Value) Then
TheForm.submit
Else
Msgbox "Please enter a numerical age."
End if
End Sub
//--＞
＜/SCRIPT＞
＜FORMmethod="POST" name=MyFormaction="myfile.asp"＞? Name: ＜INPUT typr="text" name="Name"＞
Age: ＜INPUT type="text" name="Age"＞
＜INPUT type="button" name="btnEnter"value="Enter"＞
＜/FORM＞
使用局部变量，避免使用全局变量。局部变量比全局变量更快地被Asp 脚本引擎存取，因为不需搜索整个名称域。避免改变数组定义。在第一次初始化的时候就简单分配足够的大小效率更高。在这种情况下，你可能会浪费一些内存，但你获得了速度的优势。在服务器负载重的时候这个技术是显然易见有效的。
如果你需要引用不一定要用到的对象，那么最好使用＜OBJECT＞标记而不是用 Server.CreateObject方法。 使用Server.CreateObject引起对象立即被建立，反之，＜OBJECT＞标记则不会这样立即建立对象如果使用＜object＞定义后不使用该对象，你不会浪费资源。
例如：下面的例子是一个使用＜OBJECT＞标记建立一个application-scope广告轮 Ad Rotator对象实
例：
＜OBJECT runat=server scope=Application id=MyAds progid="MSWC.AdRotator"＞
＜/OBJECT＞
在存储该Ad Rotator对象进Application后，你可以在任何程序的页面中用下面的语法访问该对象
＜%=MyAds.GetAdvertisement("CustomerAds.txt") %＞
打开'Option Explicit'开关。在VB和VBScript 中，你可以在没有显式声明的情况下使用变量。但打开这个选项可以鉴别用定义变量，这样可以很好地书写变量，并能帮助提高性能。未定义的局部变量会变慢，因为在建立它之前，名称空间必须被搜遍后才知道变量是否存在。摆脱它，使每个变量清楚地定义(先定义后使用)。
这是一个好习惯，it may trap typos, 这样更快。
除非你真正需要使用，否而不要使用Server.MapPath方法。如果你知道真实路径就使用真实路径。使用MapPath需要IIS找回现时服务器路径，这意味着得向服务器发一个特殊的请求，也就意味着降低了性能。另一个方法是将路径存放到局部变量中，在需要的时候使用，这样就不需要服务器多次查找。
检查你自己是怎么做的
你可以通过工具来测量你的系统性能，比如系统性能监视器，NetMon和PerfMon。测试web性能可以用WCAT (Web Capacity Analysis Tool)。使用WCAT，你可以测试你的IIS服务器和网络配置响应各种各样的客户请求，数据或HTML页面的能力。这些测试结果能够被用来作为优化你的服务器和网络配置的指导。WCAT是专门设计用来估计Windows 2000中的因特网服务(或Windows NT)和IIS 能响应的客户工作量
(仿真)。为了得到更多的信息，请参阅IIS Resource Kit(资源工具包)。那里也有冗长的WCAT用户指南在MSDN在线Web sorkshop站点里面有一个下载链接。如果你认真对待你的Asp 性能的话，务必取得该工具。
力求最优化应用程序性能，你的web 应用程序会运行更加顺畅。如果不是真正需要，就不要影响服务器的性能。
摘要：
上面介绍了有关ASP性能的资料，有很多因素影响Asp的性能，这里只讨论了其中的一部分。作为最终的想法，不要认为你能够处理好所有的因素，你的ASP 性能还是有必要提高的。你发布的每个应用程序必须个别进行考虑，所有以上的技巧并不是适合每个Asp程序。
This page is over.
由软件使用主页整理创作，如要引用，请指明出处，多谢
第七课.ASP提速技巧
技巧之一：提高使用Request集合的效率
访问一个ASP集合来提取一个值是费时的、占用计算资源的过程。因为这个操作包含了一系列对相关集合的搜索，这比访问
一个局部变量要慢得多。因此，如果打算在页面中多次使用Request集合中的一个值，应该考虑将其存贮为一个局部变量。
例如将代码写成下面的形式以加快脚本引擎处理速度：
strTitle=Request.Form("Title")
strFirstName=Request.Form("FirstName")
strLastName=Request.Form("LastName")
If Len(strTitle) Then strTitle=strTitle & " "
If strFirstName="" Then strFullName=strTitle & " " & strLastName
Elseif Len(strFirstName)=1 Then
strFullName=strTitle & strFirstName & ". " & strLastName
Else
strFullName=strTitle & strFirstName & " " & strLastName
End If
技巧之二：直接访问适当的集合
如果不是别无选择，否则不要使用strPage=Request("page")的这样的形式来获取参数，因为这将按顺序搜索全部的集合—
QueryString、Form、Cookies、ClientCertificate、ServerVarible直到发现第一个匹配值的名称。这样做比直接访问适
当的集合效率低，并且是不安全的，除非能绝对保证这个值不会出现在另外一个集合中。
例如，可能希望搜索满足客户请求的WEB服务器名称，这通过出现在每个查询中的Request.ServerVarables集合中寻找
“SERVER_NAME”来实现。然而，假如其他的集合也包含名为“SERVER_NAME”的值（键名不区分大小写），当使用Request
("server_Name")时，就会得到错误的结果。总而言之，应尽可能直接访问适当的集合。
技巧之三：在费时操作前使用Response.IsClientConnected属性
使用Response.IsClientConnected是观察用户是否仍连到服务器并正在载入ASP创建的网页的有用方式。如果用户断开连接
或停止下载，我们就不用再浪费服务器的资源创建网页，因为缓冲区内容将被IIS丢弃。所以，对那些需要大量时间计算或
资源使用较多的网页来说，值得在每一阶段都检查游览者是否已离线：
…… Code to create first part of the page
If Response.IsClientConnected Then
Response.Flush
Else
Response.End
End If
…… Code to create next part of page
技巧之四：优化ASP中的ADO操作
通常面言，数据构成了WEB站点的实际内容。所以，优化ADO操作以加速ASP代码执行，十分有用：
a. 仅选择所需的列：当打开ADO记录集时，除非需要获得所有的列，否则不应自动地使用表名（即SELECT *）。使用单独
的列意味着将减少发送到服务器或从服务器取出的数据量。即使需要使用全部列，单独地命名每个列也会获得最佳的性
能，因为服务器不必再解释这些列的名字。
b. 尽可能的使用存储过程。存储过程是预先编译的程序，含有一个已经准备好的执行计划，所以比SQL语句执行更快。
c. 使用适当的光标和锁定模式。如果所做的全部工作只是从记录集中读取数据，并将其显示在屏幕上，那么就使用缺省的
只能前移、只读的记录集。ADO用来维护记录和锁定的细节的工作越少，执行的性能就越高。
d. 使用对象变量。当遍历记录集时一个肯定能提高性能的方法是使用对象变量指向集合中的成员。例如：
While Not RsGc.EOF
Response.Write "工程名称：" & RsGc("GcMC") & "(工程代码：" & RsGc("GcCode") & ")
"
RsGc.MoveNext
Wend
可以用改写为下面的代码以加快执行：
set GcMc=RsGc("GcMc")
set GcCode=RsGc("GcCode")
While Not rsGc.EOF Response.Write "工程名称：" & GcMc & "(工程代码：" & GcCode & ")
" RsGc.MoveNext
Wend
新的代码建立了对象变量的引用，所以可以使用对象变量而不是实际的变量，这意味着脚本引擎的工作减少了，因为在集
合中进行索引的次数变少了。
技巧五：不要混用脚本引擎
我们知道，ASP页面中既可以使用VBScript，也可以使用JScript。但是在同一个页面上同时使用JScript和VBScript则是不
可取的。因为服务器必须实例化并尝试缓存两个（而不是一个）脚本引擎，这在一定程度上增加了系统负担。因此，从性
能上考虑，不应在同一页面中混用多种脚本引擎。
第八课.认识和优化connection对象
访问一个ASP集合来提取一个值是费时的、占用计算资源的过程。因为这个操作包含了一系列对相关集合的搜索，这比访问
一个局部变量要慢得多。因此，如果打算在页面中多次使用Request集合中的一个值，应该考虑将其存贮为一个局部变量。
例如将代码写成下面的形式以加快脚本引擎处理速度：
strTitle=Request.Form("Title")
strFirstName=Request.Form("FirstName")
strLastName=Request.Form("LastName")
If Len(strTitle) Then strTitle=strTitle & " "
If strFirstName="" Then strFullName=strTitle & " " & strLastName
Elseif Len(strFirstName)=1 Then
strFullName=strTitle & strFirstName & ". " & strLastName
Else
strFullName=strTitle & strFirstName & " " & strLastName
End If
技巧之二：直接访问适当的集合
如果不是别无选择，否则不要使用strPage=Request("page")的这样的形式来获取参数，因为这将按顺序搜索全部的集合—
QueryString、Form、Cookies、ClientCertificate、ServerVarible直到发现第一个匹配值的名称。这样做比直接访问适
当的集合效率低，并且是不安全的，除非能绝对保证这个值不会出现在另外一个集合中。
例如，可能希望搜索满足客户请求的WEB服务器名称，这通过出现在每个查询中的Request.ServerVarables集合中寻找
“SERVER_NAME”来实现。然而，假如其他的集合也包含名为“SERVER_NAME”的值（键名不区分大小写），当使用Request
("server_Name")时，就会得到错误的结果。总而言之，应尽可能直接访问适当的集合。
技巧之三：在费时操作前使用Response.IsClientConnected属性
使用Response.IsClientConnected是观察用户是否仍连到服务器并正在载入ASP创建的网页的有用方式。如果用户断开连接
或停止下载，我们就不用再浪费服务器的资源创建网页，因为缓冲区内容将被IIS丢弃。所以，对那些需要大量时间计算或
资源使用较多的网页来说，值得在每一阶段都检查游览者是否已离线：
…… Code to create first part of the page
If Response.IsClientConnected Then
Response.Flush
Else
Response.End
End If
…… Code to create next part of page
技巧之四：优化ASP中的ADO操作
通常面言，数据构成了WEB站点的实际内容。所以，优化ADO操作以加速ASP代码执行，十分有用：
a. 仅选择所需的列：当打开ADO记录集时，除非需要获得所有的列，否则不应自动地使用表名（即SELECT *）。使用单独
的列意味着将减少发送到服务器或从服务器取出的数据量。即使需要使用全部列，单独地命名每个列也会获得最佳的性
能，因为服务器不必再解释这些列的名字。
b. 尽可能的使用存储过程。存储过程是预先编译的程序，含有一个已经准备好的执行计划，所以比SQL语句执行更快。
c. 使用适当的光标和锁定模式。如果所做的全部工作只是从记录集中读取数据，并将其显示在屏幕上，那么就使用缺省的
只能前移、只读的记录集。ADO用来维护记录和锁定的细节的工作越少，执行的性能就越高。
d. 使用对象变量。当遍历记录集时一个肯定能提高性能的方法是使用对象变量指向集合中的成员。例如：
While Not RsGc.EOF
Response.Write "工程名称：" & RsGc("GcMC") & "(工程代码：" & RsGc("GcCode") & ")
"
RsGc.MoveNext
Wend
可以用改写为下面的代码以加快执行：
set GcMc=RsGc("GcMc")
set GcCode=RsGc("GcCode")
While Not rsGc.EOF Response.Write "工程名称：" & GcMc & "(工程代码：" & GcCode & ")
" RsGc.MoveNext
Wend
新的代码建立了对象变量的引用，所以可以使用对象变量而不是实际的变量，这意味着脚本引擎的工作减少了，因为在集
合中进行索引的次数变少了。
技巧五：不要混用脚本引擎
我们知道，ASP页面中既可以使用VBScript，也可以使用JScript。但是在同一个页面上同时使用JScript和VBScript则是不
可取的。因为服务器必须实例化并尝试缓存两个（而不是一个）脚本引擎，这在一定程度上增加了系统负担。因此，从性
能上考虑，不应在同一页面中混用多种脚本引擎。
第八课.认识和优化connection对象
在这个数据库连接中。我们使用了session对象，首先，建立一个conn的连接对象，然后连接到数据库data.mdb中，取得连接句柄后，把它保存在session("conn")这个session会话变量中，在打开记录集前，从session("conn")中取出句柄，借助于session对象。我们可以使不同的ASP页面共用一个连接对象，减少了对服务器内存的开销，而我们也不需要担心，当一个客户因为错误操作导致服务器不能析放该被占用的session连接对象，因为我们知道每个客户的session对象是有一定的生存期限的，过了这个期限，服务器就会自动把它析放掉。
在ASP的数据库编程中，connection对象是我们不可能离开的一个对象，在对数据库进行任何的操作，比如更新记录，插入，删除，检索等，都必须借助于connection对象来完成。形象地来说，connection对象就是程序于数据库沟通的管道，所有对数据库的操作，都必须经过它，因此，无论我们以何种方式连接数据库前，总是少不了执行下列的代码。
Set conn = Server.CreateObject("ADODB.Connection")
建立一个connection对象的实例变量，然后在它的基础上建立recorderset对象或是command对象来操作数据库。既然connection对象是如此的重要，那么如何优化和管理好connection对象对数据库程序来说是极其重要的，它关系到程序的性能。
每当一个客户执行数据库操作时，就需要借助一个connection对象，而每个connection对象就会占用服务器的一部分资源，而数据库的同时连接数不可能是无限的，因此。在考滤要提供高性能的数据库web程序时，我们需要考滤如何去减少服务器的开销。一般来说。每个asp页面中建立一个connection对象，都会在服务器中产生一个对数据库的连接。而不同的页面的connection对象是不能共享的。那么。我们可不可以使同一个用户所访问的不同页面共享一个connection连接通道呢。
大家不妨想一想我们的asp六大内建对象的session对象，他可以为某个特定的用户来保存私有的数据，如果我们把connection对象保存在session对象中，是否可以使不同的asp页面都使用同一个连接通道呢？看看下面的这段程序。
$#@60;%
Set conn = Server.CreateObject("ADODB.Connection")
DBPath = Server.MapPath("/")&"/news/data/data.mdb"
conn.Open "driver={Microsoft Access Driver (*.mdb)};dbq=" & DBPath
session("conn")=conn
Set rs = Server.CreateObject("ADODB.Recordset")
sql="select * from data"
cn=session("conn")
rs.open sql,cn,3,2
%$#@62;
d width="100%">
在这个数据库连接中。我们使用了session对象，首先，建立一个conn的连接对象，然后连接到数据库data.mdb中，取得连接句柄后，把它保存在session("conn")这个session会话变量中，在打开记录集前，从session("conn")中取出句柄，借助于session对象。我们可以使不同的ASP页面共用一个连接对象，减少了对服务器内存的开销，而我们也不需要担心，当一个客户因为错误操作导致服务器不能析放该被占用的session连接对象，因为我们知道每个客户的session对象是有一定的生存期限的，过了这个期限，服务器就会自动把它析放掉。
而ODBC3.0所提供的连接池connection pooling。也能有效地提高数据库的运行性能。我们知道，在众多的asp页面中生成的connection对象，总是处在不断建立连接，解除连接，析放连接中。
如何能高效的管理和使用好这些被废弃的连接，也可以在一定程序上大大提高运行效率。而ODBC3.0则提供了这样的功能，它能聪明的把需要新建立的连接引导至即将废弃的connection对象上，反复地使用它。这样，就能节省了不好服务器的开销。
第九课.ASP程序性能测试报告
在ASP的数据库编程中，connection对象是我们不可能离开的一个对象，在对数据库进行任何的操作，比如更新记录，插入，删除，检索等，都必须借助于connection对象来完成。形象地来说，connection对象就是程序于数据库沟通的管道，所有对数据库的操作，都必须经过它，因此，无论我们以何种方式连接数据库前，总是少不了执行下列的代码。
Set conn = Server.CreateObject("ADODB.Connection")
建立一个connection对象的实例变量，然后在它的基础上建立recorderset对象或是command对象来操作数据库。既然connection对象是如此的重要，那么如何优化和管理好connection对象对数据库程序来说是极其重要的，它关系到程序的性能。
每当一个客户执行数据库操作时，就需要借助一个connection对象，而每个connection对象就会占用服务器的一部分资源，而数据库的同时连接数不可能是无限的，因此。在考滤要提供高性能的数据库web程序时，我们需要考滤如何去减少服务器的开销。一般来说。每个asp页面中建立一个connection对象，都会在服务器中产生一个对数据库的连接。而不同的页面的connection对象是不能共享的。那么。我们可不可以使同一个用户所访问的不同页面共享一个connection连接通道呢。
大家不妨想一想我们的asp六大内建对象的session对象，他可以为某个特定的用户来保存私有的数据，如果我们把connection对象保存在session对象中，是否可以使不同的asp页面都使用同一个连接通道呢？看看下面的这段程序。
$#@60;%
Set conn = Server.CreateObject("ADODB.Connection")
DBPath = Server.MapPath("/")&"/news/data/data.mdb"
conn.Open "driver={Microsoft Access Driver (*.mdb)};dbq=" & DBPath
session("conn")=conn
Set rs = Server.CreateObject("ADODB.Recordset")
sql="select * from data"
cn=session("conn")
rs.open sql,cn,3,2
%$#@62;
d width="100%">
在这个数据库连接中。我们使用了session对象，首先，建立一个conn的连接对象，然后连接到数据库data.mdb中，取得连接句柄后，把它保存在session("conn")这个session会话变量中，在打开记录集前，从session("conn")中取出句柄，借助于session对象。我们可以使不同的ASP页面共用一个连接对象，减少了对服务器内存的开销，而我们也不需要担心，当一个客户因为错误操作导致服务器不能析放该被占用的session连接对象，因为我们知道每个客户的session对象是有一定的生存期限的，过了这个期限，服务器就会自动把它析放掉。
而ODBC3.0所提供的连接池connection pooling。也能有效地提高数据库的运行性能。我们知道，在众多的asp页面中生成的connection对象，总是处在不断建立连接，解除连接，析放连接中。
如何能高效的管理和使用好这些被废弃的连接，也可以在一定程序上大大提高运行效率。而ODBC3.0则提供了这样的功能，它能聪明的把需要新建立的连接引导至即将废弃的connection对象上，反复地使用它。这样，就能节省了不好服务器的开销。
第九课.ASP程序性能测试报告
纲要：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个指定的字段。
＜ SCRIPT LANGUAGE=VBScript RUNAT=Server ＞
Sub Application_OnStart
Application("Conn") = "Provider=SQLOLEDB; " & _
"Server=MyServer; " & _
"uid=sa; " & _
"pwd=;" & _
"DATABASE=northwind"
Application("SQL") = "SELECTTOP 0OrderID, " & _
"CustomerID, " & _
"EmployeeID, " & _
"OrderDate, " & _
"RequiredDate, " & _
"ShippedDate, " & _
"Freight " & _
"FROM[Orders] "
End Sub
＜ /SCRIPT ＞
'alternate sql - 25 records
Application("SQL") = "SELECTTOP 25OrderID, " & _
"CustomerID, " & _
"EmployeeID, " & _
"OrderDate, " & _
"RequiredDate, " & _
"ShippedDate, " & _
"Freight " & _
"FROM[Orders] "
'alternate sql - 250 records
Application("SQL") = "SELECTTOP 250 OrderID, " & _
"CustomerID, " & _
"EmployeeID, " & _
"OrderDate, " & _
"RequiredDate, " & _
"ShippedDate, " & _
"Freight " & _
"FROM[Orders] "
测试服务器配置如下：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）中，我们首先打开一个连接，然后创建记录集对象。当然，这里的脚本按照本文第一部分所总结的编码规则作了优化。
＜ % 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"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对象：
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
第二，如ADO__05.asp所示，在循环外面创建Connection对象，所有记录集共享该对象：
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
第三，如ADO__06.asp所示，在每一个循环内把连接串赋给ActiveConnection属性：
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
就象我们可以猜想到的一样，在循环内创建和拆除连接对象是效率最差的方法。不过，令人惊异的是，在循环内直接把连接串赋给ActiveConnection属性只比共享单个连接对象稍微慢了一点。
尽管如此，第三规则应该为：
l同一页面内用到多个记录集时，创建单一的连接对象并通过ActiveConnection属性共享它。
六、哪种游标类型和记录锁定方式效率最高？
迄今为止的所有测试中我们只使用了“只能向前”的游标来访问记录集。ADO为记录集提供的游标还有三种类型：静态可滚动的游标，动态可滚动的游标，键集游标。每种游标都提供不同的功能，比如访问前一记录和后一记录、是否可以看到其他程序对数据的修改等。不过，具体讨论每一种游标类型的功用已经超出了本文的范围，下表是各种游标类型的一个比较性的分析。
和“只能向前”类型的游标相比，所有其它的游标类型都需要额外的开销，而且这些游标在循环内一般也要慢一些。因此，我们愿与您共享如下告诫：永远不要这样认为——“唔，有时候我会用到动态游标，那么我就一直使用这种游标吧。”
同样的看法也适用于记录锁定方式的选择。前面的测试只用到了只读的加锁方式，但还存在其他三种方式：保守式、开放式、开放式批处理方式。和游标类型一样，这些锁定方式为处理记录集数据提供了不同的功能和控制能力。
我们得出如下规则：
l使用适合于处理任务的最简单的游标类型和记录锁定方式。
七、最好用哪种方法提取记录集？
到目前为止我们一直通过创建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对象直接创建记录集对象（CMD__02.asp）：
Set objCmd = Server.CreateObject("ADODB.Command")
objCmd.ActiveConnection = Application("Conn")
objCmd.CommandText = Application("SQL")
Set objRS = objCmd.Execute
同样，页面开销也略有增加，而单个记录的显示时间没有本质的变化。后面这两种方法在性能上的差异很小，但我们还有一个重要的问题需要考虑。
通过Recordset类创建记录集时，我们能够以最大的灵活性控制记录集的处理方式。既然后面两种方法未能有压倒性的性能表现，我们主要还是考虑默认返回的游标类型和记录锁定方式，对于某些场合来说默认值并不一定是最理想的。
因此，除非由于特殊的原因需要选择后面两种方法，否则我们建议考虑下面的规则：
l通过ADODB.Recordset类实例化记录集，以获得最好的性能和灵活性。
八、是否应该使用本地记录集？
ADO允许使用本地（客户端）记录集，此时查询将提取记录集内的所有数据，查询完成后连接可以立即关闭，以后使用本地的游标访问数据，这为释放连接带来了方便。使用本地记录集对于访问那些要求数据离线使用的远程数据服务非常重要，那么，对于普通的应用它是否同样有所帮助？
下面我们加入CursorLocation属性，并在打开记录集之后关闭了连接（CLIENT1.asp）：
Set objRS = Server.CreateObject("ADODB.Recordset")
objRS.CursorLocation = 2' adUseClient
objRS.ActiveConnection = Application("Conn")
objRS.LockType = 1?' adLockReadOnly
objRS.Open Application("SQL")
objRS.ActiveConnection = Nothing
理论上，这种方法由于以下两个原因会对效率有所好处：第一，它避免了在记录之间移动时重复地通过连接请求数据；第二，由于能够方便地释放连接，它减轻了资源需求。然而，从上表看起来使用本地记录集对提高效率显然没有什么帮助。这或许是因为使用本地记录集时，不管程序设置的是什么，游标总是变成静态类型。
第6个规则如下：
l除非确实要求记录集本地化，否则应避免使用。
十、用哪种方法引用记录集字段值效率最高？
10.1 测试
至此为止我们一直通过名字引用记录集中的字段值。由于这种方法要求每次都必须寻找相应的字段，它的效率并不高。为证明这一点，下面这个测试中我们通过字段在集合中的索引引用它的值（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
这是目前为止最好的记录。请注意单个记录的显示时间已经降低到0.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之后立即把Recordset设置成了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方法。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
虽然这种方法在速度上的好处非常明显，但它只适用于最简单的操作，根本无法适应稍微复杂的数据操作要求。
一、测试目的
本文的第一部分考察了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个指定的字段。
＜ SCRIPT LANGUAGE=VBScript RUNAT=Server ＞
Sub Application_OnStart
Application("Conn") = "Provider=SQLOLEDB; " & _
"Server=MyServer; " & _
"uid=sa; " & _
"pwd=;" & _
"DATABASE=northwind"
Application("SQL") = "SELECTTOP 0OrderID, " & _
"CustomerID, " & _
"EmployeeID, " & _
"OrderDate, " & _
"RequiredDate, " & _
"ShippedDate, " & _
"Freight " & _
"FROM[Orders] "
End Sub
＜ /SCRIPT ＞
'alternate sql - 25 records
Application("SQL") = "SELECTTOP 25OrderID, " & _
"CustomerID, " & _
"EmployeeID, " & _
"OrderDate, " & _
"RequiredDate, " & _
"ShippedDate, " & _
"Freight " & _
"FROM[Orders] "
'alternate sql - 250 records
Application("SQL") = "SELECTTOP 250 OrderID, " & _
"CustomerID, " & _
"EmployeeID, " & _
"OrderDate, " & _
"RequiredDate, " & _
"ShippedDate, " & _
"Freight " & _
"FROM[Orders] "
测试服务器配置如下：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）中，我们首先打开一个连接，然后创建记录集对象。当然，这里的脚本按照本文第一部分所总结的编码规则作了优化。
＜ % 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"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对象：
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
第二，如ADO__05.asp所示，在循环外面创建Connection对象，所有记录集共享该对象：
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
第三，如ADO__06.asp所示，在每一个循环内把连接串赋给ActiveConnection属性：
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
就象我们可以猜想到的一样，在循环内创建和拆除连接对象是效率最差的方法。不过，令人惊异的是，在循环内直接把连接串赋给ActiveConnection属性只比共享单个连接对象稍微慢了一点。
尽管如此，第三规则应该为：
l同一页面内用到多个记录集时，创建单一的连接对象并通过ActiveConnection属性共享它。
六、哪种游标类型和记录锁定方式效率最高？
迄今为止的所有测试中我们只使用了“只能向前”的游标来访问记录集。ADO为记录集提供的游标还有三种类型：静态可滚动的游标，动态可滚动的游标，键集游标。每种游标都提供不同的功能，比如访问前一记录和后一记录、是否可以看到其他程序对数据的修改等。不过，具体讨论每一种游标类型的功用已经超出了本文的范围，下表是各种游标类型的一个比较性的分析。
和“只能向前”类型的游标相比，所有其它的游标类型都需要额外的开销，而且这些游标在循环内一般也要慢一些。因此，我们愿与您共享如下告诫：永远不要这样认为——“唔，有时候我会用到动态游标，那么我就一直使用这种游标吧。”
同样的看法也适用于记录锁定方式的选择。前面的测试只用到了只读的加锁方式，但还存在其他三种方式：保守式、开放式、开放式批处理方式。和游标类型一样，这些锁定方式为处理记录集数据提供了不同的功能和控制能力。
我们得出如下规则：
l使用适合于处理任务的最简单的游标类型和记录锁定方式。
七、最好用哪种方法提取记录集？
到目前为止我们一直通过创建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对象直接创建记录集对象（CMD__02.asp）：
Set objCmd = Server.CreateObject("ADODB.Command")
objCmd.ActiveConnection = Application("Conn")
objCmd.CommandText = Application("SQL")
Set objRS = objCmd.Execute
同样，页面开销也略有增加，而单个记录的显示时间没有本质的变化。后面这两种方法在性能上的差异很小，但我们还有一个重要的问题需要考虑。
通过Recordset类创建记录集时，我们能够以最大的灵活性控制记录集的处理方式。既然后面两种方法未能有压倒性的性能表现，我们主要还是考虑默认返回的游标类型和记录锁定方式，对于某些场合来说默认值并不一定是最理想的。
因此，除非由于特殊的原因需要选择后面两种方法，否则我们建议考虑下面的规则：
l通过ADODB.Recordset类实例化记录集，以获得最好的性能和灵活性。
八、是否应该使用本地记录集？
ADO允许使用本地（客户端）记录集，此时查询将提取记录集内的所有数据，查询完成后连接可以立即关闭，以后使用本地的游标访问数据，这为释放连接带来了方便。使用本地记录集对于访问那些要求数据离线使用的远程数据服务非常重要，那么，对于普通的应用它是否同样有所帮助？
下面我们加入CursorLocation属性，并在打开记录集之后关闭了连接（CLIENT1.asp）：
Set objRS = Server.CreateObject("ADODB.Recordset")
objRS.CursorLocation = 2' adUseClient
objRS.ActiveConnection = Application("Conn")
objRS.LockType = 1?' adLockReadOnly
objRS.Open Application("SQL")
objRS.ActiveConnection = Nothing
理论上，这种方法由于以下两个原因会对效率有所好处：第一，它避免了在记录之间移动时重复地通过连接请求数据；第二，由于能够方便地释放连接，它减轻了资源需求。然而，从上表看起来使用本地记录集对提高效率显然没有什么帮助。这或许是因为使用本地记录集时，不管程序设置的是什么，游标总是变成静态类型。
第6个规则如下：
l除非确实要求记录集本地化，否则应避免使用。
十、用哪种方法引用记录集字段值效率最高？
10.1 测试
至此为止我们一直通过名字引用记录集中的字段值。由于这种方法要求每次都必须寻找相应的字段，它的效率并不高。为证明这一点，下面这个测试中我们通过字段在集合中的索引引用它的值（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
这是目前为止最好的记录。请注意单个记录的显示时间已经降低到0.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之后立即把Recordset设置成了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方法。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
虽然这种方法在速度上的好处非常明显，但它只适用于最简单的操作，根本无法适应稍微复杂的数据操作要求。
