您现在的位置： 
问题的具体方法交互。
当记录错误时，提供尽可能多的有用信息至关重要。考虑包括以下几点：
当前用户环境（调用 Win32 API ? GetUserName）
当前线程 ID（调用 Win32 API ? GetCurrentThreadId 或 Visual Basic 中的 App.ThreadId）
当前时间（使用 Win32 GetTickCount，得到的是毫秒数据）
传递至方法的参数
错误源，包括方法名
为什么
根据我们的经验，好的错误处理和记录是隔离和诊断运行时问题的最有效途径。
常见的陷阱
还记得 ASP 0115 错误吗？ 但愿您不用和它苦苦斗争了。 如果还在为其苦恼， 建议您参阅 Troubleshooting with the IIS Exception Monitor（英文）。
ASP 0115 错误不是总出现在开发人员的控制下 ? 但多数时候是这样，错误处理可能已经避免了很多这种情况的发生，还可能在其发生时帮助解决了它们。
总之，最大的问题为跳过错误处理或没有包含有用的诊断信息。
在 COM 中，罕有跨越组件的界限传播异常的情况。捕获异常 ? 但返回 HResults，以向调用者传送失败信息。
详细信息
下面的文章提供了有关有效错误处理的应用示例：
Fitch & Mather Stocks: Web Application Design（英文）
全局变量
建议
避免在组件中使用全局变量。在 Visual Basic 术语中，这表示在标准的 .BAS 模块中没有 Public 或 Global 变量。
为什么
Global 变量并不是真正意义上的全局。每个线程都有自己的副本。如果几种方法恰好在同一线程中执行，它们将看到相同的变量；否则它们访问的是这些变量的不同副本。这意味着您可能给一个全局变量赋了值（在线程 A 中），但其另一个用户（在线程 B 中执行）看不到新值。
其原因是 Visual Basic 内部使用“线程本地存储 (TLS)”来引用全局变量。这意味着每个线程都有自己的 Public 变量的副本，并且因为它存在多个副本，全局数据并不是真正“全局的”。也就是说，恰好在同一线程中运行的用户才会访问到同一个变量，不论他们是否期望如此。
常见的陷阱
如果在标准 .BAS 模块中使用 Public 变量，当不同线程向还想使用同一个数据的不同用户请求提供服务时，这个数据可能已被破坏了。
详细信息
Visual Basic Programmer's Journal（英文）1999 年 6 月版中由 Matt Curland 所著的下列文章 是必读的：
Black Belt Programming - Create Worker Threads in DLLs
COMponent Builder - Create Efficient Multithreaded Apps
另外，下面 Daniel Appleman 所著的文章 很好地概述了 Visual Basic 中多线程的工作原理： A Thread to Visual Basic（英文）
分布组件
建议
组件的分布涉及性能、可伸缩性和安全性问题。相同组件的不同分布可能产生更高性能、更易伸缩和更易管理的配置。
下面的指南有助于提高在多台计算机上分布组件时的性能和可伸缩性：
在 IIS 的同一框围中运行引用 ASP 内置对象的组件。
在应用程序服务器上运行数据库组件。
在哪一台计算机上运行业务组件很重要。倘若您去掉业务组件与任何 ASP 的耦合，您就可以根据您的应用程序设计、计算机的可用性和测试，来自由选择。
当然还有例外。但这些是指南的好的开始。
为什么
跨计算机分布组件使应用程序可以满足伸缩性要求。其次，上面提到的指南有助于实现应用程序的性能和可伸缩性目标。
对象引用 ASP 内置对象，会与您的 Web 服务器进行大量通讯，并且由于它们是表达层的一部分，因此它们就在那里。
数据库或对数据极为敏感的逻辑可能在数据库的存储过程中。将数据访问组件置于应用程序服务器而非数据库上，避免了组件之间的昂贵调用。相反，数据访问组件则利用 SQL Server 通信（如 TCP/IP）与数据库更有效地通信。
常见的陷阱
您应当尝试避免下列问题：
当横向可伸缩性较为合适之后，继续追求从您的计算机开始的纵向可伸缩性。
忽视了防火墙的考虑（帮自己一个忙。如果计算机间的产品环境有防火墙，则在测试方案中添加防火墙。）
将引用 ASP 内置对象的组件置于与 IIS 服务器分离的计算机上（回调和编组 ASP 内置对象的成本很高。）
使用组件内部的后期绑定（这产生对 GetIdsOfNames 的额外调用，这在分布式应用程序中可能很昂贵。尽量使用早期绑定。）
按引用传递参数（这产生更多的编组开销。尽可能“按值”传递参数。）
成功地从 IIS 调用远程 MTS 组件也可能很棘手。一个简单有效、既提高性能又简化安全性问题的解决方案，是调用中间的 MTS/COM+ 软件包/应用程序。早期绑定可减少网络路程段，提高性能。如果您使用“服务器”软件包/应用程序，则可以设置软件包/应用程序的运行标识。这个技术将在 KB 文章 159311 Instantiating Remote Components in Microsoft Transaction Server and Internet Information Server 中讨论。
详细信息
如果已经解耦了服务，特别是已使 ASP 在业务组件之外，则分布将相当灵活。您就可以更多地考虑框围，并根据需要分散组件以解决随之而来的可伸缩性和性能问题。如何知道？进行测试。如何测试？请看下面的基本指南：
若要测试 Web 站点的可靠性，请剖析计算机并检查错误。
若要测试性能，请查看每秒可处理多少 ASP 请求。
若要测试可伸缩性，请设置每秒需要处理多少 ASP 请求的阀值。用重要的工具考验应用程序??添加用户直到性能坏到不能接受为止。
加强对应用程序的测试非常重要，因为需要暴露运转条件和单浏览器测试中不会出现的其他问题。
有关对应用程序加强测试的详细内容， 请参阅 I Can't Stress It Enough -- Load Test Your ASP Application（英文）。
结论
正如所见，有一些事情在整个开发中需要时刻注意。在此，应用程序指南所涉及的诸多因素已全部阐明，因为它们有助于彻底避免严重失误。在整个开发周期中遵循本文中略述的几个指南，不仅可以避免一些额外的工作，而且能够提交可收缩的、可靠的、高性能的基于 ASP 组件的解决方案。
当记录错误时，提供尽可能多的有用信息至关重要。考虑包括以下几点：
当前用户环境（调用 Win32 API ? GetUserName）
当前线程 ID（调用 Win32 API ? GetCurrentThreadId 或 Visual Basic 中的 App.ThreadId）
当前时间（使用 Win32 GetTickCount，得到的是毫秒数据）
传递至方法的参数
错误源，包括方法名
为什么
根据我们的经验，好的错误处理和记录是隔离和诊断运行时问题的最有效途径。
常见的陷阱
还记得 ASP 0115 错误吗？ 但愿您不用和它苦苦斗争了。 如果还在为其苦恼， 建议您参阅 Troubleshooting with the IIS Exception Monitor（英文）。
ASP 0115 错误不是总出现在开发人员的控制下 ? 但多数时候是这样，错误处理可能已经避免了很多这种情况的发生，还可能在其发生时帮助解决了它们。
总之，最大的问题为跳过错误处理或没有包含有用的诊断信息。
在 COM 中，罕有跨越组件的界限传播异常的情况。捕获异常 ? 但返回 HResults，以向调用者传送失败信息。
详细信息
下面的文章提供了有关有效错误处理的应用示例：
Fitch & Mather Stocks: Web Application Design（英文）
全局变量
建议
避免在组件中使用全局变量。在 Visual Basic 术语中，这表示在标准的 .BAS 模块中没有 Public 或 Global 变量。
为什么
Global 变量并不是真正意义上的全局。每个线程都有自己的副本。如果几种方法恰好在同一线程中执行，它们将看到相同的变量；否则它们访问的是这些变量的不同副本。这意味着您可能给一个全局变量赋了值（在线程 A 中），但其另一个用户（在线程 B 中执行）看不到新值。
其原因是 Visual Basic 内部使用“线程本地存储 (TLS)”来引用全局变量。这意味着每个线程都有自己的 Public 变量的副本，并且因为它存在多个副本，全局数据并不是真正“全局的”。也就是说，恰好在同一线程中运行的用户才会访问到同一个变量，不论他们是否期望如此。
常见的陷阱
如果在标准 .BAS 模块中使用 Public 变量，当不同线程向还想使用同一个数据的不同用户请求提供服务时，这个数据可能已被破坏了。
详细信息
Visual Basic Programmer's Journal（英文）1999 年 6 月版中由 Matt Curland 所著的下列文章 是必读的：
Black Belt Programming - Create Worker Threads in DLLs
COMponent Builder - Create Efficient Multithreaded Apps
另外，下面 Daniel Appleman 所著的文章 很好地概述了 Visual Basic 中多线程的工作原理： A Thread to Visual Basic（英文）
分布组件
建议
组件的分布涉及性能、可伸缩性和安全性问题。相同组件的不同分布可能产生更高性能、更易伸缩和更易管理的配置。
下面的指南有助于提高在多台计算机上分布组件时的性能和可伸缩性：
在 IIS 的同一框围中运行引用 ASP 内置对象的组件。
在应用程序服务器上运行数据库组件。
在哪一台计算机上运行业务组件很重要。倘若您去掉业务组件与任何 ASP 的耦合，您就可以根据您的应用程序设计、计算机的可用性和测试，来自由选择。
当然还有例外。但这些是指南的好的开始。
为什么
跨计算机分布组件使应用程序可以满足伸缩性要求。其次，上面提到的指南有助于实现应用程序的性能和可伸缩性目标。
对象引用 ASP 内置对象，会与您的 Web 服务器进行大量通讯，并且由于它们是表达层的一部分，因此它们就在那里。
数据库或对数据极为敏感的逻辑可能在数据库的存储过程中。将数据访问组件置于应用程序服务器而非数据库上，避免了组件之间的昂贵调用。相反，数据访问组件则利用 SQL Server 通信（如 TCP/IP）与数据库更有效地通信。
常见的陷阱
您应当尝试避免下列问题：
当横向可伸缩性较为合适之后，继续追求从您的计算机开始的纵向可伸缩性。
忽视了防火墙的考虑（帮自己一个忙。如果计算机间的产品环境有防火墙，则在测试方案中添加防火墙。）
将引用 ASP 内置对象的组件置于与 IIS 服务器分离的计算机上（回调和编组 ASP 内置对象的成本很高。）
使用组件内部的后期绑定（这产生对 GetIdsOfNames 的额外调用，这在分布式应用程序中可能很昂贵。尽量使用早期绑定。）
按引用传递参数（这产生更多的编组开销。尽可能“按值”传递参数。）
成功地从 IIS 调用远程 MTS 组件也可能很棘手。一个简单有效、既提高性能又简化安全性问题的解决方案，是调用中间的 MTS/COM+ 软件包/应用程序。早期绑定可减少网络路程段，提高性能。如果您使用“服务器”软件包/应用程序，则可以设置软件包/应用程序的运行标识。这个技术将在 KB 文章 159311 Instantiating Remote Components in Microsoft Transaction Server and Internet Information Server 中讨论。
详细信息
如果已经解耦了服务，特别是已使 ASP 在业务组件之外，则分布将相当灵活。您就可以更多地考虑框围，并根据需要分散组件以解决随之而来的可伸缩性和性能问题。如何知道？进行测试。如何测试？请看下面的基本指南：
若要测试 Web 站点的可靠性，请剖析计算机并检查错误。
若要测试性能，请查看每秒可处理多少 ASP 请求。
若要测试可伸缩性，请设置每秒需要处理多少 ASP 请求的阀值。用重要的工具考验应用程序??添加用户直到性能坏到不能接受为止。
加强对应用程序的测试非常重要，因为需要暴露运转条件和单浏览器测试中不会出现的其他问题。
有关对应用程序加强测试的详细内容， 请参阅 I Can't Stress It Enough -- Load Test Your ASP Application（英文）。
结论
正如所见，有一些事情在整个开发中需要时刻注意。在此，应用程序指南所涉及的诸多因素已全部阐明，因为它们有助于彻底避免严重失误。在整个开发周期中遵循本文中略述的几个指南，不仅可以避免一些额外的工作，而且能够提交可收缩的、可靠的、高性能的基于 ASP 组件的解决方案。
