以下是一个可能出现的例外情况：当您通过防火墙进行调用时，您可能需要调用 CreateObject 而不是 Server.CreateObject。详细信息，请参阅“Q193230 - PRB: Server.CreateObject Fails when Object is Behind Firewall”（英文）。
原则 7：提供丰富的疑难解答信息
确保在您所有的 ASP 应用程序中都包含了错误处理过程。而且，确保您提供了有用的诊断信息。我还没有碰到有哪个人抱怨错误信息太具有说明性了。请确保在错误日志中包含以下信息：
- 用户上下文（如果您正在使用组件，您可以调用 GetUserName）
- 线程 ID（在组件中，可以调用 GetCurrentThreadId）<
- 时间
- 完整的错误信息（包括编号、来源和说明）
- 参数值
因为将在 ASP 下运行，您可能希望将这些信息写到文件或 NT 的事件日志。您还可以创建记录关键的应用程序事件的应用程序事件日志，以备诊断应用程序错误时使用。
以下文章提供了有关错误处理技术的详细信息：
- “Bulletproofing Your ASP Components”（英文），Charles Alexander 著
- “Fitch & Mather Stocks: Web Application Design”（英文）
- “Handling and Avoiding Web Page Errors, Part 1: The Basics”（英文）
- “Handling and Avoiding Web Page Errors, Part 2: Run-Time Errors”（英文）
- “Handling and Avoiding Web Page Errors, Part 3: An Ounce of Prevention”（英文）
原则 8：测试性能、可伸缩性和可靠性
浏览器并不是准确的测试方式，它只能向您展示应用程序可能的用途。请针对您的应用程序设置特定的性能目标，并使用 Web Application Stress Tool 等负载工具进行压力测试。您需要自己决定您的环境所能接受的条件，以下是一些帮助您启动测试过程的通用指导方针：
- 通过测试 ASP 每秒钟的请求数对性能进行测试，并建立一个最小的阈值。一般情况下，不执行数据库访问的简单 ASP 页每秒钟至少应返回 30 页。调用组件或访问数据库的页每秒钟至少返回 25 页。
- 向应用程序不停地追加用户，直到每秒钟的请求数低于预先设置的阈值，用这种方式测试可伸缩性。
- 从 Web 集群中移去机器，并检查错误和故障情况，以便测试可靠性。
将测试环境与实际运行的环境相匹配，甚至防火墙也不例外。这听起来代价很高，但我曾经听说过开发人员因为没有考虑到防火墙，而丢失了工作。