您现在的位置： 
;提供了几种构建磁盘缓存方案的工具。ADO 记录集的 Save() 和 Open() 函数，保存和加载磁盘上的记录集。您可以使用这些方法重写上面 Application 数据缓存技巧中的范例代码，用 Save() 文件替换向 Application 对象写入数据的代码。
还有其他一些处理文件的组件：
Scripting.FileSystemObject 使您能够创建、读取和写入文件。
MSXML 是随 Internet Explorer 提供的 Microsoft(R) XML 解析器，它支持保存和加载 XML 文档。
LookupTable 对象（在 MSN 上使用的范例）是从磁盘加载简单列表的良好选择。
最后，请考虑在磁盘上缓存数据的表示，而不是数据本身。预制的 HTML 可以作为 .htm 或 .asp 文件存储在磁盘上；超级链接可以直接指向这些文件。可以使用商业工具，如 XBuilder 或 Microsoft(R) SQL Server 的 Internet 发行功能来自动化 HTML 生成过程。另外，可以将 HTML 片段 #include 到 .asp 文件。还可以使用 FileSystemObject 从磁盘读取 HTML 文件或使用 XML 进行早期调整（英文）。
技巧 4：避免在 Application 或 Session 对象中缓存非灵活组件
虽然在 Application 或 Session 对象中缓存数据是个好主意，但是缓存 COM 对象可能有严重缺陷。将常用 COM 对象嵌入 Application 或 Session 对象通常具有吸引力。遗憾的是，很多 COM 对象，包括用 Visual Basic 6.0 或更早版本编写的 COM 对象，在 Application 或 Session 对象中存储时将导致严重的瓶颈。
特别是任何非灵活组件，在 Session 或 Application 对象中缓存时将导致性能瓶颈。灵活组件是标记为 ThreadingModel=Both 的组件（它聚集了自由线程汇集器 (FTM)）或标记为 ThreadingModel=Neutral 的组件（Windows(R) 2000 和 COM+ 中新增的“中性”模型。）下列组件是非灵活的：
自由线程组件（除非它们聚集了 FTM）。
单元线程组件。
单线程组件。
已配置组件（Microsoft Transaction Server (MTS)/COM+ 库和服务器包/应用程序）为非灵活组件，除非它们是“中性”线程的。单元线程组件和其他非灵活组件最适于在页作用域工作（也就是说，它们在单个 ASP 页上创建和销毁）。
在 IIS 4.0 中，标记为 ThreadingModel=Both 的组件被视为灵活的。在 IIS 5.0 中，这已经不够了。组件不仅必须标记为 Both，而且还必须聚集 FTM。灵活性文章说明了如何使得用“活动模板库”编写的 C++ 组件聚集 FTM。请注意，如果组件缓存接口指针，这些指针本身必须为灵活的、或者必须存储在“COM 全局接口表 (GIT)”中。如果不能重新编译 Both 线程组件，使它聚集 FTM，则可以将该组件标记为 ThreadingModel=Neutral。另外，如果不希望 IIS 进行灵活性检查（这样，希望非灵活组件能够存储在 Application 或 Session 作用域中），可以在 metabase 中设置 AspTrackThreadingModel 为 True。不主张更改 AspTrackThreadingModel。
如果试图在 Application 对象中存储用 Server.CreateObject 创建的非灵活组件，IIS 5.0 将产生错误。可以通过在 Global.asa 中使用 <object runat=server scope=application ...> 解决该问题，但是不主张这样做，因为这将导致汇集和串行化，说明如下。
如果缓存非灵活组件，会发生什么错误呢？缓存在 Session 对象中的非灵活组件，将把会话“锁定”到某个 ASP 工作器线程。ASP 维护着一个工作器线程池，它向请求提供服务。通常，新的请求由第一个可用的工作器线程来处理。如果 Session 被锁定到某个线程，则该请求将不得不等待它所关联的线程变为可用。打个比方：您进入一个超市，挑选了一些食品，然后在第 3 号收款台交款。从这以后，每当您在这个超市购买食品，都不得不始终在第 3 号收款台交款，即使是在其他收款台人少或没人时。
将非灵活组件存储在 Applicaton 作用域甚至会对性能产生更严重的影响。ASP 将不得不创建专用的线程来运行非灵活的、Applicaton 作用域内的组件。这将导致两种后果：所有调用不得不被汇集到该线程，而且所有调用被串行化。汇集意味着：参数不得不存储在内存的共享区；对该专用线程执行昂贵的上下文切换；组件的方法被执行；结果汇集到共享区域；以及经过另一个昂贵的上下文切换，使控制权返回原来的线程。串行化意味着所有方法必须一个挨一个地运行（同一时刻只能运行一个方法）。两个不同的 ASP 工作器线程不可能同时执行共享组件上的方法。这将扼杀并行机制，尤其是在多处理器计算机上。更坏的是，所有非灵活的、Application 作用域内的组件都将共享一个线程（“Host STA”），所以串行化的影响更加严重。
是否感到困惑？下面我们提出几个通用规则。如果您正在用 Visual Basic (6.0) 或更早版本编写对象，请不要将它们缓存在 Application 或 Session 对象中。如果您不知道对象的线程模型，就不要缓存它。不要缓存非灵活对象，而应当在每页上创建并释放它们。对象将直接运行在 ASP 工作器线程上，这样，将不会发生汇集或串行化。如果 COM 对象正运行在 IIS 框中，而且如果它们没有花很长时间来初始化和取消，性能将是足够的。注意，不要用该方法使用单线程对象。小心：VB 可以创建单线程的对象！如果您必须以该方式使用单线程的对象（如 Microsoft Excel 电子表格），则不要期望有很高的吞吐量。
当 ADO 被标记为自由线程时，则缓存 ADO 记录集是安全的。要将 ADO 标记为自由线程，请使用 Makfre15.bat 文件，该文件通常位于如下目录中：\Program FilesCommonSystemADO。
警告： 如果您正在用 Microsoft Access 作为数据库，则不应当将 ADO 标记为自由线程。通常，ADO 记录集还必须是断开连接的，如果您不能控制站点的 ADO 配置（例如，您是独立的软件厂商 [ISV]，将 Web 应用程序卖给客户，然后由他们来管理他们自己的配置），那么不缓存记录集可能会更好。
词典组件也是灵活对象。LookupTable 从数据文件加载它的数据，并且它对组合框数据和配置信息是有用的。来自 Duwamish Books 的 PageCache 对象提供了目录语义，和 Caprock Dictionary 的表现一样。这些对象或它们的派生对象可以构成有效缓存策略的基础。注意，Scripting.Dictionary 对象不是灵活的，所以不应当存储在 Application 或 Session 作用域。
技巧 5：不要在 Application 或 Session 对象中缓存数据库连接
缓存 ADO 连接通常是不好的策略。如果一个 Connection 对象存储在 Application 中，并在所有页上使用，那么所有页将竞争使用该连接。如果 Connection 对象存储在 ASP Session 对象中，那么将为每个用户创建数据库连接。这将连接池的好处毁于一旦，并对 Web 服务器和数据库产生不必要的压力。
取代缓存数据库连接的方法是，在每个使用 ADO 的 ASP 页上创建并取消 ADO 对象。这是个有效的方法，因为 IIS 具有内置的数据库连接池。更准确的说，IIS 自动启用 OLEDB 和 ODBC 连接池。这确保了创建并取消每个页上的连接将是有效的。
由于被连接的记录集中存储有对数据库连接的引用，所以，不应当在 Application 或 Session 对象中缓存被连接的记录集。但是，可以安全地缓存断开连接的记录集，因为它不包含对其数据连接的引用。要断开记录集的连接，请执行如下两个步骤：
Set rs = Server.CreateObject("ADODB.RecordSet")
rs.CursorLocation = adUseClient ' 第 1 步
' 植入带数据的记录集
rs.Open strQuery, strProv
' 现在断开记录集同数据提供者和数据源的连接
rs.ActiveConnection = Nothing ' 第 2 步
有关连接池的详细信息，请参阅 ADO 和 SQL Server（英文）引用。
技巧 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&n
还有其他一些处理文件的组件：
Scripting.FileSystemObject 使您能够创建、读取和写入文件。
MSXML 是随 Internet Explorer 提供的 Microsoft(R) XML 解析器，它支持保存和加载 XML 文档。
LookupTable 对象（在 MSN 上使用的范例）是从磁盘加载简单列表的良好选择。
最后，请考虑在磁盘上缓存数据的表示，而不是数据本身。预制的 HTML 可以作为 .htm 或 .asp 文件存储在磁盘上；超级链接可以直接指向这些文件。可以使用商业工具，如 XBuilder 或 Microsoft(R) SQL Server 的 Internet 发行功能来自动化 HTML 生成过程。另外，可以将 HTML 片段 #include 到 .asp 文件。还可以使用 FileSystemObject 从磁盘读取 HTML 文件或使用 XML 进行早期调整（英文）。
技巧 4：避免在 Application 或 Session 对象中缓存非灵活组件
虽然在 Application 或 Session 对象中缓存数据是个好主意，但是缓存 COM 对象可能有严重缺陷。将常用 COM 对象嵌入 Application 或 Session 对象通常具有吸引力。遗憾的是，很多 COM 对象，包括用 Visual Basic 6.0 或更早版本编写的 COM 对象，在 Application 或 Session 对象中存储时将导致严重的瓶颈。
特别是任何非灵活组件，在 Session 或 Application 对象中缓存时将导致性能瓶颈。灵活组件是标记为 ThreadingModel=Both 的组件（它聚集了自由线程汇集器 (FTM)）或标记为 ThreadingModel=Neutral 的组件（Windows(R) 2000 和 COM+ 中新增的“中性”模型。）下列组件是非灵活的：
自由线程组件（除非它们聚集了 FTM）。
单元线程组件。
单线程组件。
已配置组件（Microsoft Transaction Server (MTS)/COM+ 库和服务器包/应用程序）为非灵活组件，除非它们是“中性”线程的。单元线程组件和其他非灵活组件最适于在页作用域工作（也就是说，它们在单个 ASP 页上创建和销毁）。
在 IIS 4.0 中，标记为 ThreadingModel=Both 的组件被视为灵活的。在 IIS 5.0 中，这已经不够了。组件不仅必须标记为 Both，而且还必须聚集 FTM。灵活性文章说明了如何使得用“活动模板库”编写的 C++ 组件聚集 FTM。请注意，如果组件缓存接口指针，这些指针本身必须为灵活的、或者必须存储在“COM 全局接口表 (GIT)”中。如果不能重新编译 Both 线程组件，使它聚集 FTM，则可以将该组件标记为 ThreadingModel=Neutral。另外，如果不希望 IIS 进行灵活性检查（这样，希望非灵活组件能够存储在 Application 或 Session 作用域中），可以在 metabase 中设置 AspTrackThreadingModel 为 True。不主张更改 AspTrackThreadingModel。
如果试图在 Application 对象中存储用 Server.CreateObject 创建的非灵活组件，IIS 5.0 将产生错误。可以通过在 Global.asa 中使用 <object runat=server scope=application ...> 解决该问题，但是不主张这样做，因为这将导致汇集和串行化，说明如下。
如果缓存非灵活组件，会发生什么错误呢？缓存在 Session 对象中的非灵活组件，将把会话“锁定”到某个 ASP 工作器线程。ASP 维护着一个工作器线程池，它向请求提供服务。通常，新的请求由第一个可用的工作器线程来处理。如果 Session 被锁定到某个线程，则该请求将不得不等待它所关联的线程变为可用。打个比方：您进入一个超市，挑选了一些食品，然后在第 3 号收款台交款。从这以后，每当您在这个超市购买食品，都不得不始终在第 3 号收款台交款，即使是在其他收款台人少或没人时。
将非灵活组件存储在 Applicaton 作用域甚至会对性能产生更严重的影响。ASP 将不得不创建专用的线程来运行非灵活的、Applicaton 作用域内的组件。这将导致两种后果：所有调用不得不被汇集到该线程，而且所有调用被串行化。汇集意味着：参数不得不存储在内存的共享区；对该专用线程执行昂贵的上下文切换；组件的方法被执行；结果汇集到共享区域；以及经过另一个昂贵的上下文切换，使控制权返回原来的线程。串行化意味着所有方法必须一个挨一个地运行（同一时刻只能运行一个方法）。两个不同的 ASP 工作器线程不可能同时执行共享组件上的方法。这将扼杀并行机制，尤其是在多处理器计算机上。更坏的是，所有非灵活的、Application 作用域内的组件都将共享一个线程（“Host STA”），所以串行化的影响更加严重。
是否感到困惑？下面我们提出几个通用规则。如果您正在用 Visual Basic (6.0) 或更早版本编写对象，请不要将它们缓存在 Application 或 Session 对象中。如果您不知道对象的线程模型，就不要缓存它。不要缓存非灵活对象，而应当在每页上创建并释放它们。对象将直接运行在 ASP 工作器线程上，这样，将不会发生汇集或串行化。如果 COM 对象正运行在 IIS 框中，而且如果它们没有花很长时间来初始化和取消，性能将是足够的。注意，不要用该方法使用单线程对象。小心：VB 可以创建单线程的对象！如果您必须以该方式使用单线程的对象（如 Microsoft Excel 电子表格），则不要期望有很高的吞吐量。
当 ADO 被标记为自由线程时，则缓存 ADO 记录集是安全的。要将 ADO 标记为自由线程，请使用 Makfre15.bat 文件，该文件通常位于如下目录中：\Program FilesCommonSystemADO。
警告： 如果您正在用 Microsoft Access 作为数据库，则不应当将 ADO 标记为自由线程。通常，ADO 记录集还必须是断开连接的，如果您不能控制站点的 ADO 配置（例如，您是独立的软件厂商 [ISV]，将 Web 应用程序卖给客户，然后由他们来管理他们自己的配置），那么不缓存记录集可能会更好。
词典组件也是灵活对象。LookupTable 从数据文件加载它的数据，并且它对组合框数据和配置信息是有用的。来自 Duwamish Books 的 PageCache 对象提供了目录语义，和 Caprock Dictionary 的表现一样。这些对象或它们的派生对象可以构成有效缓存策略的基础。注意，Scripting.Dictionary 对象不是灵活的，所以不应当存储在 Application 或 Session 作用域。
技巧 5：不要在 Application 或 Session 对象中缓存数据库连接
缓存 ADO 连接通常是不好的策略。如果一个 Connection 对象存储在 Application 中，并在所有页上使用，那么所有页将竞争使用该连接。如果 Connection 对象存储在 ASP Session 对象中，那么将为每个用户创建数据库连接。这将连接池的好处毁于一旦，并对 Web 服务器和数据库产生不必要的压力。
取代缓存数据库连接的方法是，在每个使用 ADO 的 ASP 页上创建并取消 ADO 对象。这是个有效的方法，因为 IIS 具有内置的数据库连接池。更准确的说，IIS 自动启用 OLEDB 和 ODBC 连接池。这确保了创建并取消每个页上的连接将是有效的。
由于被连接的记录集中存储有对数据库连接的引用，所以，不应当在 Application 或 Session 对象中缓存被连接的记录集。但是，可以安全地缓存断开连接的记录集，因为它不包含对其数据连接的引用。要断开记录集的连接，请执行如下两个步骤：
Set rs = Server.CreateObject("ADODB.RecordSet")
rs.CursorLocation = adUseClient ' 第 1 步
' 植入带数据的记录集
rs.Open strQuery, strProv
' 现在断开记录集同数据提供者和数据源的连接
rs.ActiveConnection = Nothing ' 第 2 步
有关连接池的详细信息，请参阅 ADO 和 SQL Server（英文）引用。
技巧 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&n
