改进性能和样式的 25+ ASP 技巧(2)
2001-04-13 10:17:23 来源：WEB开发网核心提示：技巧 6：妙用 session 对象 在肯定了在 applications 和 Sessions 中缓存的优点之后，我们建议您避免使用 Session 对象，改进性能和样式的 25+ ASP 技巧(2)，下面将会谈到，当用于忙碌站点时，这是非常可怕的低效率（而且非常慢），用 VBScript 编写该代码实现的快速方法为
技巧 6：妙用 session 对象
在肯定了在 applications 和 Sessions 中缓存的优点之后，我们建议您避免使用 Session 对象。下面将会谈到，当用于忙碌站点时，Sessions 有几个缺点。所谓忙碌，通常是指站点每秒请求数百页或同时有数千个用户。该技巧对于必须进行水平扩展的站点，即那些利用多个服务器来适应负载或执行容错功能的站点来说，更加重要。对于较小的站点，如 intranet 站点，Sessions 的便利，与开销相比也是值得的。
为了翻新，asp 自动为每个访问 Web 服务器的用户创建一个 Session。每个 Session 有大约 10 KB 内存开销（在存储在 Session 中的任何数据中是最高的），并使所有的请求都慢了一点。Session 一直保持活动状态，直到达到可配置的超时（通常 20 分钟）为止。
Session 最大的问题不是性能而是可伸缩性。Session 不能跨越 Web 服务器；一旦在一个服务器上创建了 Session，它的数据就保持在那里。这意味着，如果您在 Web 领域中使用 Sessions，您将不得不为每个用户的请求设计一种策略，以便始终将这些请求引向用户的 Session 所在的服务器。这被称为将用户“粘”到 Web 服务器上。术语“粘性会话”即来源于此。由于 Session 没有保持到磁盘上，所以，当 Web 服务器崩溃时，被“粘住”的用户将丢失他们的 Sessions 状态。
用于实施粘性会话的策略包括硬件和软件解决方案。如 Windows 2000 Advanced Server 中的网络负载平衡解决方案和 Cisco 公司的“本地指向器”解决方案可以实施粘性会话，但以牺牲一些可伸缩性为代价。这些解决方案并不完美。我们不主张您现在全盘推翻您的软件解决方案（我们过去常用 ISAPI 筛选器和 URL 矫直对方案进行检查）。
Application 对象也不能跨越服务器；如果您需要在 Web 领域内共享并更新 Application 数据，则需要使用后端数据库。但只读的 Application 数据在 Web 领域中仍然有用。
如果只是为了增加正常运行时间（用于处理故障转移和服务器维护），大多数执行重要任务的站点将需要部署至少两台 Web 服务器。所以，在设计执行重要任务的应用程序时，您将需要实施“粘性会话”，或者简单地避开 Sessions 以及其他任何在单个 Web 服务器上存储用户状态的状态管理技术。
如果当前没有使用 Sessions，请确保将它们关闭。可以通过“Internet 服务管理器”（请参阅 ISM 文档）来为应用程序执行该操作。如果决定使用 Sessions，可以采取几个方法来将对性能的影响降低到最小。
可以将不需要 Sessions 的内容（如“帮助”屏幕、访问者区域等）移动到关闭了 Sessions 的、单独的 ASP 应用程序中。可以逐页提示 ASP：在给定的页中您不需要 Session 对象；使用位于 ASP 页顶端的如下指令：
<% @EnableSessionState=False %>
使用该指令的一个很好的原因是，Session 给框架集带来了有趣的问题。ASP 保证任何时候只执行一个来自 Session 的请求。这样可以确保如果浏览器为一个用户请求了多个页时，在每一时刻只有一个 ASP 请求将进入 Session；这就避免了在访问 Session 对象时出现多线程问题。遗憾的是，结果，框架集中的所有页均被以串行化方式绘制，一个接一个地，而不是同时地。这样，用户可能不得不等待很长时间才能得到所有框架内容。这意味着：如果某些框架页不信任 Session，一定要使用 @EnableSessionState=False 指令告诉 ASP。
作为使用 Session 对象的替代方式，有很多方法可以用来管理 Session 状态。对于状态数量较小的情况（不到 4 KB），通常建议使用 Cookies、QueryString 变量和隐藏形式的变量。对于较大数量的数据，如购物推车，则使用后端数据库是最合适的选择。关于在 Web 服务器领域中的状态管理技术已经有很多资料。详细信息，请参阅 会话状态（英文）。
技巧 7：在 COM 对象中封装代码
如果您有很多 VBScript 或 JScript，那么您可以通过把代码移动到已编译的 COM 对象来经常改进它们的性能。已编译的代码通常比被解释代码运行得更快。已编译的 COM 对象可以通过“早期绑定”访问其他 COM 对象，这种调用 COM 对象方法的手段，比脚本所使用的“后期绑定”更有效。
将代码封装在 COM 对象种有如下好处（超越性能）：
COM 对象是将表达逻辑与业务逻辑分隔开来的好办法。
COM 对象启用了代码重用。
很多开发商发现，用 VB、C++ 或 Visual J++ 书写的代码，比 ASP 更容易调试。
COM 对象有一些缺点，包括初始开发时间以及需要不同的编程技巧。需要警告您的是，封装“少”量的 ASP 可能会导致性能降低，而不是提高。通常，在少量 ASP 代码封装到 COM 对象时出现这样的情况。这时候，创建和调用 COM 对象的开销，超过了已编译代码的好处。至于 ASP 脚本和 COM 对象代码怎样合并才能产生最佳性能还有待测试。注意，与 Windows NT(R) 4.0/IIS 4.0 相比，Microsoft 已经在 Windows 2000/IIS 5.0 中极大地提高了脚本和 ADO 性能。这样，已编译代码对 ASP 代码的性能优势已经随着 IIS 5.0 的引入而降低。
有关在 ASP 中使用 COM 对象的优缺点的更多讨论，请参阅 ASP 组件准则和用 COM 和 Microsoft Visual Basic 6.0 对分布式应用程序进行编程（英文）。如果您的确部署了 COM 组件，要对它们进行强度测试是非常重要的。实际上，所有 ASP 应用程序都应当作为正式过程进行强度测试。
技巧 8：晚点获取资源，早点释放资源
这是个小技巧。通常，最好晚点获取资源而要早点释放资源。这些资源包括 COM 对象、文件句柄和其他资源。
ADO 连接和记录集是这种优化的首要目标。当您使用完记录集，就是说用它的数据打印完一个表格后，请立即将它释放，而不是等到页的末尾。将您的 VBScript 变量设置为 Nothing 是最好的做法。不要让记录集简单地脱离作用域。同时，应当释放任何有关的 Command 或 Connection 对象。（不要忘了对记录集或“连接”调用 Close()，在将它们设置为 = Nothing 之前。）这将缩短数据库必须为您调整资源的时间跨度，并将数据库连接尽可能快地释放给连接池。
技巧 9：进程外的执行将牺牲可靠性
ASP 和 MTS/COM+ 都有允许您以可靠性换取性能的配置选项。当建立和部署应用程序时，应当理解这种交换。
ASP 选项
ASP 应用程序可以配置为以三种方式之一运行。在 IIS 5.0 中引入了术语“隔离级”来描述这些选项。三个隔离级值分别是低、中和高：
低级隔离。该隔离级在所有版本的 IIS 中受到支持，并且是最快的。它在主 IIS 进程 Inetinfo.exe 中执行 ASP。如果 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 文件中显式使用选项 Explicit。置于 .asp 文件开头的这一指令，强制开发人员声明所有要使用的变量。许多开发人员认为这有助于调试应用程序，因为它避免了错误键入变量名称而不经意地新建变量（例如，MyXLMString=... 而非 MyxmlString=)。
也许更重要的是，声明的变量比未声明的变量快。实际上，脚本运行时，在每次使用未声明变量时按照名称引用。而声明的变量，在编译或运行时分配了序号。这样，声明的变量按照该序号引用。由于选项 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 ' 对 blah 做一次解析
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 编程同样有效。
在肯定了在 applications 和 Sessions 中缓存的优点之后，我们建议您避免使用 Session 对象。下面将会谈到，当用于忙碌站点时，Sessions 有几个缺点。所谓忙碌，通常是指站点每秒请求数百页或同时有数千个用户。该技巧对于必须进行水平扩展的站点，即那些利用多个服务器来适应负载或执行容错功能的站点来说，更加重要。对于较小的站点，如 intranet 站点，Sessions 的便利，与开销相比也是值得的。
为了翻新，asp 自动为每个访问 Web 服务器的用户创建一个 Session。每个 Session 有大约 10 KB 内存开销（在存储在 Session 中的任何数据中是最高的），并使所有的请求都慢了一点。Session 一直保持活动状态，直到达到可配置的超时（通常 20 分钟）为止。
Session 最大的问题不是性能而是可伸缩性。Session 不能跨越 Web 服务器；一旦在一个服务器上创建了 Session，它的数据就保持在那里。这意味着，如果您在 Web 领域中使用 Sessions，您将不得不为每个用户的请求设计一种策略，以便始终将这些请求引向用户的 Session 所在的服务器。这被称为将用户“粘”到 Web 服务器上。术语“粘性会话”即来源于此。由于 Session 没有保持到磁盘上，所以，当 Web 服务器崩溃时，被“粘住”的用户将丢失他们的 Sessions 状态。
用于实施粘性会话的策略包括硬件和软件解决方案。如 Windows 2000 Advanced Server 中的网络负载平衡解决方案和 Cisco 公司的“本地指向器”解决方案可以实施粘性会话，但以牺牲一些可伸缩性为代价。这些解决方案并不完美。我们不主张您现在全盘推翻您的软件解决方案（我们过去常用 ISAPI 筛选器和 URL 矫直对方案进行检查）。
Application 对象也不能跨越服务器；如果您需要在 Web 领域内共享并更新 Application 数据，则需要使用后端数据库。但只读的 Application 数据在 Web 领域中仍然有用。
如果只是为了增加正常运行时间（用于处理故障转移和服务器维护），大多数执行重要任务的站点将需要部署至少两台 Web 服务器。所以，在设计执行重要任务的应用程序时，您将需要实施“粘性会话”，或者简单地避开 Sessions 以及其他任何在单个 Web 服务器上存储用户状态的状态管理技术。
如果当前没有使用 Sessions，请确保将它们关闭。可以通过“Internet 服务管理器”（请参阅 ISM 文档）来为应用程序执行该操作。如果决定使用 Sessions，可以采取几个方法来将对性能的影响降低到最小。
可以将不需要 Sessions 的内容（如“帮助”屏幕、访问者区域等）移动到关闭了 Sessions 的、单独的 ASP 应用程序中。可以逐页提示 ASP：在给定的页中您不需要 Session 对象；使用位于 ASP 页顶端的如下指令：
<% @EnableSessionState=False %>
使用该指令的一个很好的原因是，Session 给框架集带来了有趣的问题。ASP 保证任何时候只执行一个来自 Session 的请求。这样可以确保如果浏览器为一个用户请求了多个页时，在每一时刻只有一个 ASP 请求将进入 Session；这就避免了在访问 Session 对象时出现多线程问题。遗憾的是，结果，框架集中的所有页均被以串行化方式绘制，一个接一个地，而不是同时地。这样，用户可能不得不等待很长时间才能得到所有框架内容。这意味着：如果某些框架页不信任 Session，一定要使用 @EnableSessionState=False 指令告诉 ASP。
作为使用 Session 对象的替代方式，有很多方法可以用来管理 Session 状态。对于状态数量较小的情况（不到 4 KB），通常建议使用 Cookies、QueryString 变量和隐藏形式的变量。对于较大数量的数据，如购物推车，则使用后端数据库是最合适的选择。关于在 Web 服务器领域中的状态管理技术已经有很多资料。详细信息，请参阅 会话状态（英文）。
技巧 7：在 COM 对象中封装代码
如果您有很多 VBScript 或 JScript，那么您可以通过把代码移动到已编译的 COM 对象来经常改进它们的性能。已编译的代码通常比被解释代码运行得更快。已编译的 COM 对象可以通过“早期绑定”访问其他 COM 对象，这种调用 COM 对象方法的手段，比脚本所使用的“后期绑定”更有效。
将代码封装在 COM 对象种有如下好处（超越性能）：
COM 对象是将表达逻辑与业务逻辑分隔开来的好办法。
COM 对象启用了代码重用。
很多开发商发现，用 VB、C++ 或 Visual J++ 书写的代码，比 ASP 更容易调试。
COM 对象有一些缺点，包括初始开发时间以及需要不同的编程技巧。需要警告您的是，封装“少”量的 ASP 可能会导致性能降低，而不是提高。通常，在少量 ASP 代码封装到 COM 对象时出现这样的情况。这时候，创建和调用 COM 对象的开销，超过了已编译代码的好处。至于 ASP 脚本和 COM 对象代码怎样合并才能产生最佳性能还有待测试。注意，与 Windows NT(R) 4.0/IIS 4.0 相比，Microsoft 已经在 Windows 2000/IIS 5.0 中极大地提高了脚本和 ADO 性能。这样，已编译代码对 ASP 代码的性能优势已经随着 IIS 5.0 的引入而降低。
有关在 ASP 中使用 COM 对象的优缺点的更多讨论，请参阅 ASP 组件准则和用 COM 和 Microsoft Visual Basic 6.0 对分布式应用程序进行编程（英文）。如果您的确部署了 COM 组件，要对它们进行强度测试是非常重要的。实际上，所有 ASP 应用程序都应当作为正式过程进行强度测试。
技巧 8：晚点获取资源，早点释放资源
这是个小技巧。通常，最好晚点获取资源而要早点释放资源。这些资源包括 COM 对象、文件句柄和其他资源。
ADO 连接和记录集是这种优化的首要目标。当您使用完记录集，就是说用它的数据打印完一个表格后，请立即将它释放，而不是等到页的末尾。将您的 VBScript 变量设置为 Nothing 是最好的做法。不要让记录集简单地脱离作用域。同时，应当释放任何有关的 Command 或 Connection 对象。（不要忘了对记录集或“连接”调用 Close()，在将它们设置为 = Nothing 之前。）这将缩短数据库必须为您调整资源的时间跨度，并将数据库连接尽可能快地释放给连接池。
技巧 9：进程外的执行将牺牲可靠性
ASP 和 MTS/COM+ 都有允许您以可靠性换取性能的配置选项。当建立和部署应用程序时，应当理解这种交换。
ASP 选项
ASP 应用程序可以配置为以三种方式之一运行。在 IIS 5.0 中引入了术语“隔离级”来描述这些选项。三个隔离级值分别是低、中和高：
低级隔离。该隔离级在所有版本的 IIS 中受到支持，并且是最快的。它在主 IIS 进程 Inetinfo.exe 中执行 ASP。如果 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 文件中显式使用选项 Explicit。置于 .asp 文件开头的这一指令，强制开发人员声明所有要使用的变量。许多开发人员认为这有助于调试应用程序，因为它避免了错误键入变量名称而不经意地新建变量（例如，MyXLMString=... 而非 MyxmlString=)。
也许更重要的是，声明的变量比未声明的变量快。实际上，脚本运行时，在每次使用未声明变量时按照名称引用。而声明的变量，在编译或运行时分配了序号。这样，声明的变量按照该序号引用。由于选项 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 ' 对 blah 做一次解析
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 编程同样有效。
中查找“改进性能和样式的 25+ ASP 技巧(2)”更多相关内容
中查找“改进性能和样式的 25+ ASP 技巧(2)”更多相关内容更多精彩
赞助商链接
