微软建议的ASP性能优化28条守则
技巧 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 MyArray()
Redim MyArray(2)
MyArray(0) = ?hello?
MyArray(1) = ?good-bye?
MyArray(2) = ?farewell?
...
' some other code where you end up needing more space happens, then ...
Redim Preserve MyArray(5)
MyArray(3) = ?more stuff?
MyArray(4) = ?even more stuff?
MyArray(5) = ?yet more stuff?
%>
最好一开始就将数组的初始大小 Dim 正确(在本例中,是 5)比 Redim 数组使其更大好得多。您可能浪费一些内存(如果您没有使用所有的元素),但获得的好处是速度变得更快。
技巧 14:使用响应缓冲
您可以通过启用“响应缓冲”,将要输出的一整页缓冲起来。这样就将写到浏览器的量减到最少,从而改善总体性能。每个写操作都会产生很大的系统开销(在 IIS 中以及在通过网络发送的数据量方面),因此写操作越少越好。由于其启动慢且使用 Nagling 算法(用来减轻网络塞车情况),TCP/IP 在发送一些大的数据块时比必须发送许多小的数据块时的效率高得多。
有两个方法启用响应缓冲。第一种,您可以使用 Internet Services Manager 为整个应用程序启用响应缓冲。我们建议采用这种方法,在 IIS 4.0 和 IIS 5.0 中默认为新的 ASP 应用程序启用响应缓冲。第二种,可以在每个 ASP 页面的接近顶端的地方加入下面的代码行,从而启用响应缓冲:
<% Response.Buffer = True %>
此代码行必须在任何响应数据被写到浏览器之前执行(即,在任何 HTML 出现在 ASP 脚本之前以及在使用 Response.Cookies 集合设置任何 Cookies 之前)。一般来说,最好为整个应用程序启用响应缓冲。这样,您就不必在每个页面最上面写入上述的代码行。
Response.Flush
关于响应缓冲有一个常见的抱怨,就是用户感觉到 ASP 页面的响应速度很慢(即使整个响应时间得到改进),因为他们必须等到整个页面生成,然后他们才能看到东西。对于运行时间长的页面,您可以设置 Response.Buffer = False,禁用响应缓冲。但是,一个更好的策略是利用 Response.Flush 方法。这种方法将 ASP 转换的所有 HTML 送到浏览器。例如,在转换 1,000 行的表的前 100 行之后,ASP 可以调用 Response.Flush,强制将转换的结果送到浏览器,这样可使用户在其余的行准备好之前看到头 100 行。这种技术可以将响应缓冲与浏览器逐渐显示数据完美地结合在一起。
(注意在上面的 1,000 行表的举例中,许多浏览器在它们看到关闭 </table> 标记之前不会开始显示表。检查您的目标浏览器是否支持。为避免这种情况,将表分成多个具有较少行的表,并在每个表之后调用 Response.Flush。较新版本的 Internet Explorer 在表完全下载之前就开始显示表,如果您指定表列宽,显示速度就会特别快,这样做可避免强制 Internet Explorer 通过测量每个单元格的内容宽度来计算列宽。)
另一个关于响应缓冲的常见的抱怨是,当产生非常大的页面时,将占用许多服务器内存。撇开产生大页面的方法不谈,这种问题也可通过巧妙使用 Response.Flush 来加以解决。
技巧 15:批处理内嵌脚本和 Response.Write 语句
VBScript 语法 <% = expression %> 将“expression”的值写到 ASP 输出流中。如果响应缓冲未启用,那么执行其中的每一条语句,都会以许多小的数据包通过网络将数据写到浏览器中。这样速度很慢。而且穿插执行少量的脚本和 HTML,将引起脚本引擎和 HTML 之间的切换,从而降低性能。因此,使用下面的技巧:使用 Response.Write 调用代替捆绑紧密的内嵌表达式。例如,在下面的示例中,在每一行的每一字段对响应流有一次写操作,每一行在 VBScript 和 HTML 之间有许多切换:
<table>
<% For Each fld in rs.Fields %>
<th><% = fld.Name %></th>
<%
Next
While Not rs.EOF
%>
<tr>
<% For Each fld in rs.Fields %>
<td><% = fld.Value %></td>
<% Next
</tr>
<% rs.MoveNext
Wend %>
</table>
下面的代码更有效,每一行对响应流有一次写操作。所有的代码都包含在一个 VBScript 块内:
<table>
<%
For each fld in rs.Fields
Response.Write (?<th>? & fld.Name & ?</th>? & vbCrLf)
Next
While Not rs.EOF
Response.Write (?<tr>?)
For Each fld in rs.Fields %>
Response.Write(?<td>? & fld.Value & ?</td>? & vbCrLf)
Next
Response.Write ?</tr>?
Wend
%>
</table>
当禁用响应缓冲时,这一技巧的效果特别大。最好启用响应缓冲,然后看批处理 Response.Write 是否有助于提高性能。
(在这一特定举例中,建立表主体的嵌套循环 (While Not rs.EOF...) 可以用仔细构建的 GetString 调用来替代。)