ASP性能优化28条守则

        性能是一个特征。您必须预先设计性能，否则您以后就得重写应用程序。就是说，有哪些好的策略可使 Active Server Pages (ASP) 应用程序性能达到最佳？

　　本文介绍了优化 ASP 应用程序和 Visual Basic® Scripting Edition (VBScript) 的技巧。本文讨论了许多陷阱。本文列出的建议已经在 http://www.microsoft.com 和其它站点中进行了测试，效果十分显著。本文假定您已经对 ASP 开发，包括 VBScript 和/或 JScript、ASP Application、ASP Session 和其它 ASP 固有对象（Request、Response 和 Server）有了基本了解。

　　通常，ASP 性能主要取决于 ASP 代码本身以外的很多因素。我们不在一篇文章中罗列出所有的信息，在本文结尾处我们列出了与性能有关的资源。这些链接涵盖了 ASP 和非 ASP 主题，包括 ActiveX® 数据对象 (ADO)、组件对象模型 (COM)、数据库和 Internet Information Server (IIS) 配置。这些都是我们喜欢的一些链接 - 一定要去看看。

技巧 1：将经常使用的数据缓存在 Web 服务器上

　　典型的 ASP 页从后端数据存储中检索数据，然后将结果转换成超文本标记语言 (HTML)。无论数据库的速度如何，从内存中检索数据总要比从后端数据存储中检索数据快得多。从本地硬盘读取数据通常也比从数据库中检索数据更快。因此，通常可以将数据缓存在 Web 服务器上（存储在内存或磁盘中），来提高性能。

　　缓存是传统的以空间换取时间的做法。如果您缓存的内容正确，那么您可以看到性能会有显著的提高。为使缓存有效，必须保存那些经常重复使用的数据，且要重新计算这些数据需要（适度）大的开销。如果缓存的都是些陈旧的数据，就会造成内存浪费。

　　不经常发生改变的数据是很好的缓存候选数据，因为您不必担心随着时间的迁移该数据与数据库同步的问题。组合框列表、引用表、DHTML 碎片、扩展标记语言 (XML) 字符串、菜单项和站点配置变量（包括数据源名称 (DSN)、Internet 协议 (IP) 地址和 Web 路径）都是很好的缓存候选内容。注意您可以缓存数据的“表示”，而不缓存数据本身。如果 ASP 页很少更改，且缓存的开销也很大（例如，整个产品目录），则应考虑事先产生 HTML，而不是在响应每个请求时重新显示。

　　应将数据缓存在哪里，有哪些缓存策略？通常，数据缓存在 Web 服务器的内存或磁盘中。下两个技巧讲述了这两个方法。

技巧 2: 将经常使用的数据缓存在 Application 或 Session 对象中

　　ASP Application 和 Session 对象为将数据缓存在内存中提供了方便的容器。您可以将数据指派到 Application 和 Session 对象中，这些数据在 HTTP 调用之间保留在内存中。Session 数据是按每个用户分别存储的，而 Application 数据则在所有用户之间共享。

　　什么时候将数据装载到 Application 或 Session 中呢？通常，数据是在启动 Application 或 Session 时装载。要在 Application 或 Session 启动过程中装载数据，应将适当的代码分别添加到 Application_OnStart() 或 Session_OnStart() 中。这些函数应在 Global.asa 中，如果没有，则可以添加这些函数。还可以在第一次需要时装载该数据。为此，在 ASP 页中添加一些代码（或编写一个可重复使用的脚本函数），以检查数据是否存在，如果不存在，就装载数据。这是一个传统的性能技术，称为“惰性计算” - 在您知道需要某一个值以前不计算该值。例如：

<!---->
　　可以为所需要的每个数据块编写类似的函数。

　　应以什么格式存储数据？可以存储任何变体类型，因为所有脚本变量都是变体型。例如，您可以存储字符串、整数或数组。通常，您将以这些变量类型之一存储 ADO 记录集的内容。要从 ADO 记录集获取数据，您可以手工将数据复制到 VBScript 变量，一次一个字段。使用一个 ADO 记录集持久函数 GetRows()、GetString() 或 Save()(ADO 2.5)，可加快速度且更容易一些。其详细情况已超出本文所讨论的范围，但下面给出了一个函数举例，说明使用 GetRows() 返回记录集数据的一个数组：

' Get Recordset, return as an Array
Function FetchEmploymentStatusList
Dim rs
Set rs = CreateObject(?ADODB.Recordset?)
rs.Open ?select StatusName, StatusID from EmployeeStatus?, _
?dsn=employees;uid=sa;pwd=;?
FetchEmploymentStatusList = rs.GetRows() ? Return data as an Array
rs.Close
Set rs = Nothing
End Function

　　对上面举例做更进一步改进，可以将 HTML 缓存为列表，而不是数组。下面是简单的示例：

' Get Recordset, return as HTML Option list
Function FetchEmploymentStatusList
Dim rs, fldName, s
Set rs = CreateObject(?ADODB.Recordset?)
rs.Open ?select StatusName, StatusID from EmployeeStatus?, _
?dsn=employees;uid=sa;pwd=;?
s = ?? & vbCrLf Set fldName = rs.Fields(?StatusName?) ' ADO Field Binding Do Until rs.EOF ' Next line violates Don't Do String Concats, ' but it's OK because we are building a cache s = s & ? ? & fldName & ? ? & vbCrLf rs.MoveNext Loop s = s & ?? & vbCrLf
rs.Close
Set rs = Nothing ' See Release Early
FetchEmploymentStatusList = s ' Return data as a String
End Function
　　在适当的条件下，可以将 ADO 记录集本身缓存在 Application 或 Session 作用域中。有两个警告：

　　必须将 ADO 标记为自由线程
　　必须使用断开连接的记录集。
　　如果不能保证满足这两个要求，则不要缓存 ADO 记录集。在下面的“非敏捷组件”和“不要缓存连接”技巧中，我们将讨论将 COM 对象存储在 Application 或 Session 作用域中的危险性。

　　当您将数据存储在 Application 或 Session 作用域时，数据将保留在那里，直到您以编程方式改变它、Session 过期或 Web 应用程序重新启动为止。如果数据需要更新怎么办？要手工强制对 Application 数据进行更新，您可以访问只有管理员才可访问的 ASP 页来更新数据。或者，您可以通过函数定期自动刷新数据。下面例子存储带有缓存数据的时间戳，并隔一段时间后刷新数据。

<!---->

　　使用这一指令有一个很好的理由是，这些 Session 在框架集方面存在一个有意思的问题。ASP 保证任何时候 Session 只有一个请求执行。这样就确保如果浏览器为一个用户请求多个页面，一次只有一个 ASP 请求接触 Session，这样就避免了当访问 Session 对象时发生的多线程问题。很遗憾，一个框架集中的所有页面将以串行方式显示，一个接一个，而不是同时显示。用户可能必须等候很长时间，才能看到所有的框架。该故事的寓意：如果某些框架集页面不依靠 Session，一定要使用 @EnableSessionState=False 指令告诉 ASP。

　　有许多管理 Session 状态的方法，可替代 Session 对象的使用。对于少量的状态（少于 4 KB），我们通常建议使用 Cookies、QueryString 变量和隐式变量。对于更大数据量，如购物小车，后端数据库是最适合的选择。有关 Web 服务器群中状态管理技术的文章很多。有关详细信息，请参见 Session 状态参考资料。

技巧 7: 将代码封装在 COM 对象中

　　如果您有许多 VBScript 或 JScript，您可以经常将代码移到编译的 COM 对象中，从而可改善性能。编译的代码通常比解释的代码运行得更快。编译的 COM 对象可以通过“早绑定”访问其它 COM 对象，与脚本使用的“晚绑定”相比，“早绑定”是调用 COM 对象的更有效方法。

　　将代码封装在 COM 对象中还有一些优点（除性能之外）：

　　COM 对象有利于将表示逻辑与业务逻辑分开。
　　COM 对象可以保证代码重复使用。
　　许多开发人员发现以 VB、C++ 或 Visual J++ 编写的代码比 ASP 更容易调试。
　　COM 对象也有缺点，包括初始开发时间和需要不同的程序设计技巧。注意封装少量的 ASP 可能引起性能下降，而不会得到性能改进。这种情况通常在少量的 ASP 代码被封装进 COM 对象时发生。在这种情况下，创建和调用 COM 对象的系统开销超过了编译的代码的优点。应反复地试验，以确定什么样的 ASP 脚本和 COM 对象代码的组合产生最好的性能。注意，与 Microsoft Windows NT® 4.0/IIS 4.0 相比，Windows 2000/IIS 5.0 中在脚本和 ADO 性能方面有了很大的改进。因此，随着 IIS 5.0 的推出，编译代码比 ASP 代码的性能优势有所降低。

　　有关在 ASP 中使用 COM 的优点和缺点的详细讨论，参见 ASP Component Guidelines and Programming Distributed Applications with and Microsoft Visual Basic 6.0。如果您部署 COM 组件，以负荷对它们进行测试特别重要。事实上，理所当然应对所有的 ASP 应用程序进行负荷测试。

技巧 8：迟一点获得资源，早一点释放资源

　　这里是一个小技巧供您参考。一般来说，最好迟一点获得资源，早一点释放资源。这适用于 COM 对象以及文件句柄和其它资源。

　　这种优化方法主要用于 ADO 连接和记录集。当您使用完记录集，比方说在显示一个表及其数据之后，应立即释放它，而不是等到页面结束时再释放。将 VBScript 变量设置为 Nothing 是最好的做法。不要让记录集超出作用域之外。而且，要释放任何相关的 Command 或 Connection 对象（在将记录集或连接设置为 = Nothing 之前，不要忘记调用 Close()）。这会缩短数据库必须为您准备资源的时间，并尽快释放数据库到连接池的连接。

技巧 9：进程外执行过程以性能换取可靠性

　　ASP 和 MTS/COM+ 两者都有配置选项，可使您兼顾可靠性和性能。当建立和部署应用程序时，应知道如何兼顾两者的性能。

　　ASP 选项
　　可以配置 ASP 应用程序，以便以三种方法之一运行。在 IIS 5.0 中，引入了“隔离级”这一术语以说明这些选项。这三个隔离级分别是低级、中级和高级：

　　低级隔离。这在 IIS 的所有版本中都得到支持，且是最快的。它在 Inetinfo.exe 中运行 ASP，Inetinfo.exe 是主要 IIS 进程。如果 ASP 应用程序崩溃，IIS 也会崩溃。（要在 IIS 4.0 下重新启动 IIS，Web 站点管理员应使用诸如 InetMon 之类的工具监视站点，如果服务器发生故障，应启用批处理文件以重新启动服务器。IIS 5.0 引入了可靠的重新启动，该方法可使发生故障的服务器自动重新启动。）
　　中级隔离。IIS 5.0 引入了这个新的级别，它被称为进程外级别，因为 ASP 在 IIS 进程之外运行。在中级隔离中，被配置作为中级隔离运行的所有 ASP 应用程序都共享一个进程空间。这就减少了在一台服务器运行多个进程外 ASP 应用程序所需要的进程数量。中级隔离是 IIS 5.0 中的默认隔离级别。
　　高级隔离。在 IIS 4.0 和 IIS 5.0 中支持这一级别，高级隔离也是进程外的。如果 ASP 崩溃，Web 服务器并不会崩溃。下次 ASP 请求时，ASP 应用程序就会自动重新启动。在高级隔离中，配置作为高级隔离运行的每个 ASP 应用程序都在其自有进程空间中运行。这样做可保护 ASP 应用程序彼此之间不相互干扰。其缺点是它要求每个 ASP 应用程序都要有一个单独的进程。当在一台服务器上必须运行许多应用程序时，系统开销就会大大增加。
　　哪个选项最好的呢？在 IIS 4.0 中，进程外运行将显著降低性能。在 IIS 5.0 中，做了许多改进，将进程外运行 ASP 应用程序所产生的开销降到最低限度。事实上，在绝大多数测试中，IIS 5.0 中的 ASP 进程外应用程序比 IIS 4.0 中的进程内应用程序运行得更快。不管怎样，在两个平台上，进程内（低隔离级）性能最佳。但是，如果访问率相对较低或最大吞吐量较低，低隔离级的优势不太明显。因此，在您每一 Web 服务器每秒钟需要数百或成千上万页面时，才会觉得有必要设置低隔离级。与往常一样，应对多种配置进行测试，确定您要采取哪一种折衷方案。

　　注意 当您运行 ASP 进程外应用程序时（中级或高级隔离），它们在 NT4 中的 MTS 和在 Windows 2000 中的 COM+ 中运行。即，在 NT4 中它们在 Mtx.exe 中运行；而在 Windows 2000 中，它们在 DllHost.exe 中运行。您可以在任务管理器中看到这些进程在运行。您还可以看到 IIS 如何为进程外 ASP 应用程序配置 MTS 程序包或 COM+ 应用程序。

　　COM 选项
　　COM 组件也有三种配置选项，虽然与 ASP 选项不完全类似。COM 组件可以是“未配置的”、配置为库应用程序或配置为服务器应用程序。“未配置的”意思是指组件没有注册 COM+。组件将在调用程序的进程空间运行，那就是说，它们是“进程内的”。库应用程序也是进程内的，但使用 COM+ 的服务，包括安全、事务和上下文支持。服务器应用程序被配置为在它们自有的进程空间内运行。

　　您可以看到未配置的组件比库应用程序略有一些优势。库应用程序比服务器应用程序的性能优点更大。这是因为库应用程序与 ASP 在同一进程内运行，而服务器应用程序在它们的自有进程内运行。进程间的调用比进程内调用开销更大。而且，当在进程之间传递诸如记录集之类的数据时，必须在两个进程之间复制所有的数据。

　　陷阱！当使用 COM 服务器应用程序时，如果您在 ASP 和 COM 之间传递对象，要确保对象执行“按值汇集”或 MBV。执行 MBV 的对象将它们自己从一个进程复制到另一个进程。这比下面一种方法好，采用这种方法时，对象仍在创建者的进程中，另外一个进程反复地调用创建进程以使用该对象。切断连接的 ADO 记录集将“按值汇集”，连接的记录集则不然。Scripting.Dictionary 不执行 MBV，且不在进程之间传递。最后，VB 程序员请注意：MBV 不通过传递参数 ByVal 获得。MBV 稍嫉淖榧髡咧葱小?

　　怎么办？
　　如果让我们建议一个兼顾性能与可靠性的合理配置，它们应是如下的配置：

　　在 IIS 4.0 中，使用 ASP 低隔离级别，使用 MTS 服务器程序包。
　　在 IIS 5.0 上，使用 ASP 的中隔离级，并使用 COM+ 库应用程序。
这些是非常一般的原则，主机服务公司一般情况下以中或高隔离级运行 ASP，而单用途的 Web 服务器可以以低隔离级运行。衡量各种利弊，并自己决定哪个配置更能符合您的需要。

 

技巧 10：使用显式选项

　　在 .asp 文件中应使用 Option Explicit。此指令放在 .asp 文件的最上面，它强制开发人员声明要使用到的所有变量。许多程序员认为这种方法对于调试应用程序很有帮助，因为这种方法避免了键错变量名和误建新变量的可能性（例如，将 MyXMLString=) 错写成 MyXLMString=...。

　　更重要的一点也许是，声明的变量比未声明的变量速度更快。由此，脚本在运行时每次用到未声明的变量时，按名称引用它。另一方面，声明的变量是有顺序的，要么以编译时间，要么以运行时间。以后，声明的变量都按此顺序引用。因为 Option Explicit 强制变量声明，它能确保声明所有变量，因此访问的速度也很快。

技巧 11：在子例程和函数中使用局部变量

　　局部变量是那些在子例程和函数内声明的变量。在函数或子例程内，局部变量访问比全局变量访问更快。局部变量的使用也会使代码更清晰，因此应尽量使用局部变量。

技巧 12：将经常使用的数据复制到脚本变量中

　　当访问 ASP 中的 COM 对象时，应将经常使用的对象数据复制到脚本变量中。这样做可减少 COM 方法调用，因为 COM 方法调用与访问脚本变量相比，开销相对较大。当访问 Collection 和 Dictionary 对象时，这种技术也会减少开销很大的查找。

　　一般来说，如果您打算不止一次访问对象数据，那么就应将数据放到脚本变量中。这种优化的主要目标是 Request 变量（Form 和 QueryString 变量）。例如，您的站点可传递一个名为 UserID 的 QueryString 变量。假设此 UserID 在特定页面上被引用 12 次。可以无须调用 Request(?UserID?) 12 次，而是在 ASP 页面最上面将 UserID 指派到一个变量。然后在该页面自始至终使用该变量。这样就省去了 11 次 COM 方法调用。

　　实际上，访问 COM 属性或方法的开销并没有那么大。下面举一个例子，说明某相当常见的代码（从语法上讲）：

Foo.bar.blah.baz = Foo.bar.blah.qaz(1)
If Foo.bar.blah.zaq = Foo.bar.blah.abc Then ' ...
　　当此代码运行时，下面是发生的情况：

　　变量 Foo 被解析为全局对象。
　　变量 bar 被解析为 Foo 的成员。这实际就是一次 COM 方法调用。
　　变量 blah 被解析为 Foo.bar 的成员。这又是一次 COM 方法调用。
　　变量 qaz 被解析为 foo.bar.blah 的成员。没有错，这还是一次 COM 方法调用。
　　调用 Foo.bar.blah.quaz(1)。再一次 COM 方法调用。懂了吗？
　　再次执行步骤 1 至步骤 3 以解析 baz。系统并不知道调用 qaz 是否改变对象模型，因此必须再次执行步骤 1 至 3 以解析 baz。
　　将 baz 解析为 Foo.bar.blah 的成员。赋予属性。
　　再次执行步骤 1 至步骤 3 以解析 zaq。
　　再次执行步骤 1 至步骤 3 以解析 abc。
　　正如您可看到的，效率相当差（且慢）。以 VBScript 写此代码的快速方法是：

Set myobj = Foo.bar.blah ' do the resolution of blah ONCE
Myobj.baz = myobj.qaz(1)
If Myobj.zaq = Myobj.abc Then '...
　　如果您使用 VBScript 5.0 或更高版本，您可以使用 With 语句写此代码：

With Foo.bar.blah
.baz = .qaz(1)
If .zaq = .abc Then '...
...
End With

　　注意此技巧也适用于 VB 程序设计。

技巧 13：避免重新确定数组的维数

　　应尽量避免 Redim 数组。就性能而言，如果计算机的物理内存大小有限，最好将数组的初始维数设置为其最不利的情况 - 或将维数设置为其最佳的情况，然后再按需要重新确定维数。这并非意味着，如果知道您不需要内存时，就随便分配几兆字节的内存。

　　下面的代码给您显示使用 Dim 和 Redim 不当的情形。

<!---->

　　最好一开始就将数组的初始大小 Dim 正确（在本例中，是 5）比 Redim 数组使其更大好得多。您可能浪费一些内存（如果您没有使用所有的元素），但获得的好处是速度变得更快。

 

技巧 14：使用响应缓冲

　　您可以通过启用“响应缓冲”，将要输出的一整页缓冲起来。这样就将写到浏览器的量减到最少，从而改善总体性能。每个写操作都会产生很大的系统开销（在 IIS 中以及在通过网络发送的数据量方面），因此写操作越少越好。由于其启动慢且使用 Nagling 算法（用来减轻网络塞车情况），TCP/IP 在发送一些大的数据块时比必须发送许多小的数据块时的效率高得多。

　　有两个方法启用响应缓冲。第一种，您可以使用 Internet Services Manager 为整个应用程序启用响应缓冲。我们建议采用这种方法，在 IIS 4.0 和 IIS 5.0 中默认为新的 ASP 应用程序启用响应缓冲。第二种，可以在每个 ASP 页面的接近顶端的地方加入下面的代码行，从而启用响应缓冲：

<!---->
　　此代码行必须在任何响应数据被写到浏览器之前执行（即，在任何 HTML 出现在 ASP 脚本之前以及在使用 Response.Cookies 集合设置任何 Cookies 之前）。一般来说，最好为整个应用程序启用响应缓冲。这样，您就不必在每个页面最上面写入上述的代码行。

　　Response.Flush
　　关于响应缓冲有一个常见的抱怨，就是用户感觉到 ASP 页面的响应速度很慢（即使整个响应时间得到改进），因为他们必须等到整个页面生成，然后他们才能看到东西。对于运行时间长的页面，您可以设置 Response.Buffer = False，禁用响应缓冲。但是，一个更好的策略是利用 Response.Flush 方法。这种方法将 ASP 转换的所有 HTML 送到浏览器。例如，在转换 1,000 行的表的前 100 行之后，ASP 可以调用 Response.Flush，强制将转换的结果送到浏览器，这样可使用户在其余的行准备好之前看到头 100 行。这种技术可以将响应缓冲与浏览器逐渐显示数据完美地结合在一起。

　　（注意在上面的 1,000 行表的举例中，许多浏览器在它们看到关闭 标记之前不会开始显示表。检查您的目标浏览器是否支持。为避免这种情况，将表分成多个具有较少行的表，并在每个表之后调用 Response.Flush。较新版本的 Internet Explorer 在表完全下载之前就开始显示表，如果您指定表列宽，显示速度就会特别快，这样做可避免强制 Internet Explorer 通过测量每个单元格的内容宽度来计算列宽。）

　　另一个关于响应缓冲的常见的抱怨是，当产生非常大的页面时，将占用许多服务器内存。撇开产生大页面的方法不谈，这种问题也可通过巧妙使用 Response.Flush 来加以解决。

技巧 15：批处理内嵌脚本和 Response.Write 语句

　　VBScript 语法 <!---->将“expression”的值写到 ASP 输出流中。如果响应缓冲未启用，那么执行其中的每一条语句，都会以许多小的数据包通过网络将数据写到浏览器中。这样速度很慢。而且穿插执行少量的脚本和 HTML，将引起脚本引擎和 HTML 之间的切换，从而降低性能。因此，使用下面的技巧：使用 Response.Write 调用代替捆绑紧密的内嵌表达式。例如，在下面的示例中，在每一行的每一字段对响应流有一次写操作，每一行在 VBScript 和 HTML 之间有许多切换：

<!---->

<!---->

　　下面的代码更有效，每一行对响应流有一次写操作。所有的代码都包含在一个 VBScript 块内：

? & fld.Value & ?

　　当禁用响应缓冲时，这一技巧的效果特别大。最好启用响应缓冲，然后看批处理 Response.Write 是否有助于提高性能。

　　（在这一特定举例中，建立表主体的嵌套循环 (While Not rs.EOF...) 可以用仔细构建的 GetString 调用来替代。）

技巧 16：如果页面需要很长时间才能完成，那么执行前使用 Response.IsClientConnected

　　如果用户性急，他们可能会在您开始执行他们的请求之前，就会放弃 ASP 页面。如果他们单击刷新或移到服务器上的另一个页面，在 ASP 请求队列的末尾就有一个新的请求等候，在队列的中间有一个断开连接的请求。当服务器的负载很高时（因此请求队列就会很长，响应时间也会相应地变长），就会经常发生这种情况，这样只能使情况变得更糟。如果用户不再连接，执行 ASP 页面（特别是慢的、大的 ASP 页面）已没有任何意义。您可以使用 Response.IsClientConnected 属性检查这一情况。如果它返回 False，则应调用 Response.End 并放弃页的其余部分。事实上，IIS 5.0 已将这一做法编为程序 - 每当 ASP 即将执行新请求时，它就会检查请求在队列中已等候了多长时间。如果已经在那里等候了多于 3 秒钟，ASP 将检查客户机是否仍处于连接状态，如果没有连接，就立即终止请求。您可以在配置数据库中使用 AspQueueConnectionTestTime 设置将超时时间由 3 秒调整为其它值。

　　如果页面要花很长时间才能执行完，也可以不时地检查 Response.IsClientConnected。当启用了响应缓冲时，最好不时地执行 Response.Flush，以用户知道，正在发生什么事。

　　注意 在 IIS 4.0 上，除非先执行了 Response.Write，否则 Response.IsClientConnected 就不能正常工作。如果启用了缓冲，您也必须执行 Response.Flush。在 IIS 5.0 上，却没有必要这样做，- Response.IsClientConnected 工作正常。在任何情况下，Response.IsClientConnected 都会有一些开销，因此只有在一个操作至少要花（比方说） 500 毫秒（如果您想维持每秒钟数十页的吞吐量，这是一个很长的时间）才使用它。经验表明，不要每次重复执行紧密循环时都调用它，如显示表的许多行时 - 每隔二十或五十行调用一次可能比较合适。
巧 17：使用标记声明它们，而不使用 Server.CreateObject 方法。Server.CreateObject 能立即创建对象。如果以后不再使用该对象，您就浪费了资源。