微软建议的ASP性能优化28条守则(3)

您可以看到未配置的组件比库应用程序略有一些优势。库应用程序比服务器应用程序的性能优点更大。这是因为库应用程序与 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 方法调