ASP指南

对于一些简单的数据，您可以使用QueryStringcookie或隐藏的窗体域保持ASP请求间的状态。然后，对于更为复杂的信息，通常推荐您使用数据库。一般所采用的方式是生成某一特有的标识符，然后发送到每一个发出请求的客户机，并保存为隐藏的窗体域。在随后的请求中，这一特有的标识符被用于在数据库中查找与该用户相关的状态信息。这一方式提供了更高的可伸缩性和更为简洁明了的代码。

有关使用QueryStringcookie和隐藏的窗体域的详细信息，请参阅“Q175167HOWTO:PersistingValuesWithoutSessions”（英文）。

原则6：使用Server.CreateObject创建对象

在创建ASP技术的对象时，您可以选择<OBJECT>标记、Server.CreateObject和CreateObject三种方式。每项技术的行为略有不同。尽管在IIS4.0中，使用<OBJECT>标记或CreateObject比Server.CreateObject略具性能优势，我们一般还是推荐使用Server.CreateObject，以便于ASP应用程序认知您的对象。（注意在IIS5.0中，前两项与Server.CreateObject相比，已经没有性能优势。）

<OBJECT>标记仅在调用第一个方法时才会创建组件，因此能够节省资源。Server.CreateObject使用ASP技术内置的Server对象创建组件。实质上，它只是执行了CoCreateInstance，但是ASP却能够认知这一对象。同时，还将调用ASP技术的传统的OnStartPage和OnEndPage。（注意最好在IIS4.0或者更高版本中使用ObjectContext）。如果您只是使用CreateObject，您将越过ASP技术而直接使用Scripting引擎。

以下是一个可能出现的例外情况：当您通过防火墙进行调用时，您可能需要调用CreateObject而不是Server.CreateObject。详细信息，请参阅“Q193230-PRB:Server.CreateObjectFailswhenObjectisBehindFirewall”（英文）。

原则7：提供丰富的疑难解答信息

确保在您所有的ASP应用程序中都包含了错误处理过程。而且，确保您提供了有用的诊断信息。我还没有碰到有哪个人抱怨错误信息太具有说明性了。请确保在错误日志中包含以下信息：

• 用户上下文（如果您正在使用组件，您可以调用GetUserName）
• 线程ID（在组件中，可以调用GetCurrentThreadId）<
• 时间
• 完整的错误信息（包括编号、来源和说明）
• 参数值

因为将在ASP下运行，您可能希望将这些信息写到文件或NT的事件日志。您还可以创建记录关键的应用程序事件的应用程序事件日志，以备诊断应用程序错误时使用。

以下文章提供了有关错误处理技术的详细信息：

• “BulletproofingYourASPComponents”（英文），CharlesAlexander著
• “Fitch&MatherStocks:WebApplicationDesign”（英文）
• “HandlingandAvoidingWebPageErrors,Part1:TheBasics”（英文）
• “HandlingandAvoidingWebPageErrors,Part2:Run-TimeErrors”（英文）
• “HandlingandAvoidingWebPageErrors,Part3:AnOunceofPrevention”（英文）

原则8：测试性能、可伸缩性和可靠性

浏览器并不是准确的测试方式，它只能向您展示应用程序可能的用途。请针对您的应用程序设置特定的性能目标，并使用WebApplicationStressTool等负载工具进行压力测试。您需要自己决定您的环境所能接受的条件，以下是一些帮助您启动测试过程的通用指导方针：

• 通过测试ASP每秒钟的请求数对性能进行测试，并建立一个最小的阈值。一般情况下，不执行数据库访问的简单ASP页每秒钟至少应返回30页。调用组件或访问数据库的页每秒钟至少返回25页。
• 向应用程序不停地追加用户，直到每秒钟的请求数低于预先设置的阈值，用这种方式测试可伸缩性。
• 从Web集群中移去机器，并检查错误和故障情况，以便测试可靠性。

将测试环境与实际运行的环境相匹配，甚至防火墙也不例外。这听起来代价很高，但我曾经听说过开发人员因为没有考虑到防火墙，而丢失了工作。

有关使用WebApplicationStressTool测试ASP应用程序的详细信息，请参阅“ICan"tStressItEnough--LoadTestYourASPApplication”（英文）。

原则9：增加隔离性

使用隔离功能保护您的应用程序过程能够极大地增强服务器的稳定性。谈到Internet应用程序，是否使用隔离功能的后果可能会有巨大的差别：一个是应用程序崩溃，一个是服务器当机。保护主IIS进程(InetInfo.exe)通常会排在优先级列表的较高位置。在您使用组件时，这一点尤为突出。

通常所采用的保护主ISS进程的技术是使Web应用程序运行在各自的内存空间中。在InternetServicesManager中，您可以针对每一个Web设置这一选项。虽然因对进程进行编组而开销的系统资源会对性能有些微的影响，但对应用程序所起的保护作用值得付出这一代价。在IIS4.0下，您可以采用进程内(in-process)和进程外（out-of-process，OOP）两种方式运行应用程序。OOP应用程序会运行在新的Mtx.exe实例中。在IIS5.0下，您还能使用其他的隔离选项。可以将隔离级别设置为“低”（对Inetinfo.exe来说是进程内应用程序）、“中”（DllHost.exe共享实例）或“高”（Dllhost.exe的非共享实例）。

除了将Web应用程序隔离在它们自己的内存空间中之外，您可能还希望隔离不信任的组件。不信任的组件通常是在实际环境中没有通过测试时间的考验的组件。您可以在Server包中运行这些组件，这样它们会运行在新的Dllhost.exe实例中。

一般而言，如果要在性能和保护措施之间采取中庸之道，方式如下：在“高”隔离状态运行Web应用程序，在库包中运行组件。这种方式最大限度地减少了编组开支，同时在进程之间提供了最强的保护作用。

详细信息，请参阅文章“ServerReliabilityThroughProcessIsolation”（英文）。

原则10：不要滥用线程共用组

在IIS4.0下，针对每个受MTS管理的处理器，ASP的默认共用组是10个线程。在IIS5.0中，默认值是20。这就意味着每一线程都是一份潜在的宝贵资源，能够处理多个客户机请求。您同样需要避免调用会出现阻塞的方法，如进行大的数据库调用。如果您有要执行这种操作的工作，它将阻止ASP应用程序将响应快速返回到客户机，则请考虑使用队列功能。例如，在NT4.0中，可以使用MSMQ。在Windows2000中，可以使用QueuedComponents（排队组件）。

在会话中不要存储Single-threadedApartment(STA)组件，这种方式的一个共同缺陷是会填满会话范围中的VisualBasic对象。会将用户锁定到某一线程，与线程共用组的目的背道而驰。潜在的用户会被阻塞在其他用户的后面，等待创建他们组件的线程变得有效。您应该采用别的方式，设计能基于每一页进行创建和破坏的无状态组件。

快速提示：确保已在服务器上禁用了ASPScriptDebugging功能（使用InternetServicesManager）。如果启用了ASPScriptDebugging，则ASP的执行过程将被锁定到某一线程。

详细信息，请参阅以下文章：

• “Q243544INFO:ComponentThreadingModelSummaryUnderActiveServerPage”（英文）
• “Q191979PRB:VBComponentNotMarkedApartmentProducesASP0115Error”（英文）
• “Q243548INFO:DesignGuidelinesforVBComponentsUnderASP”（英文）
• “Q243543INFO:DoNotStoreSTAObjectsinSessionorApplication”（英文）
• “TuningInternetInformationServerPerformance”（英文）

摘要

创建ASP应用程序需要相当宽广的知识面。ASP应用程序所面临的一个挑战是目前没有通用的规则（这也正是乐趣的一部分）。另外一个问题是许多开发人员接触Internet开发之前是从事桌面系统的开发工作。通过在您的ASP开发工作中应用上述规则，您有希望避免犯下代价巨大的错误，并能开发出相当不错的ASP应用程序。