以下是一个可能出现的例外情况：当您通过防火墙进行调用时，您可能需要调用 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 集群中移去机器，并检查错误和故障情况，以便测试可靠性。将测试环境与实际运行的环境相匹配，甚至防火墙也不例外。这听起来代价很高，但我曾经听说过开发人员因为没有考虑到防火墙，而丢失了工作。
有关使用 Web Application Stress Tool 测试 ASP 应用程序的详细信息，请参阅“I Can't Stress It Enough -- Load Test Your ASP Application”（英文）。
原则 9：增加隔离性
使用隔离功能保护您的应用程序过程能够极大地增强服务器的稳定性。谈到 Internet 应用程序，是否使用隔离功能的后果可能会有巨大的差别：一个是应用程序崩溃，一个是服务器当机。保护主 IIS 进程 (InetInfo.exe) 通常会排在优先级列表的较高位置。在您使用组件时，这一点尤为突出。
