您现在的位置： 
ion 对象中。但是，您可以安全地缓存断开连接的记录集，它们不保存到其数据连接的引用。要断开记录集连接，执行下面的两个步骤：
Set rs = Server.CreateObject(?ADODB.RecordSet?)
rs.CursorLocation = adUseClient ' step 1
' Populate the recordset with data
rs.Open strQuery, strProv
' Now disconnect the recordset from the data provider and data source
rs.ActiveConnection = Nothing ' step 2
有关连接池的更详细信息，可以在 ADO 和 SQL Server 参考资料中找到。
技巧 6：合理地使用 Session 对象
既然我们已经讨论了缓存在 Application 和 Session 中的优点，现在开始讨论避免使用 Session 对象的问题。正如下面所讨论的，当与忙的站点一起使用时，Session 有几个缺点。“忙”的意思一般是指一秒钟要求几百页面或成千上万同时用户的站点。这个技巧对于必须水平扩展的站点 - 即，那些利用多台服务器以处理负载或实现容错的站点 - 甚至更重要。对于较小的站点，诸如 Intranet 站点，要想实现 Session 带来的方，必然增大系统开销。
简言之，ASP 自动为每个访问 Web 服务器的用户创建一个 Session。每个 Session 大约需要 10 KB 的内存开销（最主要的是数据存储在 Session 中），这就使所有的请求都减慢。在配置的超时时段（通常是 20 分钟）结束以前，Session 一直保留有效。
Session 的最大的问题不是性能，而是可扩展性。Session 不能跨越几台 Web 服务器，一旦在一台服务器上创建 Session，其数据就留在那儿。这就意味着如果您在一个 Web 服务器群使用 Session，您必须设计一个策略，将每个用户请求始终发到用户 Session 所在的那台服务器上。这被称为将用户“粘”在 Web 服务器上。术语“粘性会话”就是从这里派生而来的。如果 Web 服务器崩溃，被“粘住的”用户将丢失他们的会话状态，因为会话不是粘到磁盘上。
实现粘性会话的策略包括硬件和软件解决方案。诸如 Windows 2000 Advanced Server 中的网络负载平衡和 Cisco 的 Local Director 之类的解决方案都可以实现粘性会话，代价是要损失一定程度的可扩展性。这些解决方案是不完善的。不建议此时部署您自己的软件解决方案（我们过去常常使用 ISAPI 筛选器和 URL 转换等等）。
Application 对象也不跨越多台服务器，如果您必须跨越 Web 服务器群共享和更新 Application 数据，您必须使用后端数据库。但是，只读 Application 数据在 Web 服务器群中仍是有用的。
如果只是因为要增加运行时间（处理故障转移和服务器维护），大多数关键任务站点至少需部署两台 Web 服务器。因此，在设计关键任务应用程序时，必须实现“粘性会话”，或干脆避免使用 Session，以及任何其它将用户状态存储在单个 Web 服务器上的状态管理技术。
如果您不使用 Session，一定要将它们关闭。您可以通过 Internet Services Manager，为应用程序执行此操作（参见 ISM 文档）。如果您决定使用 Session，您可以采用一些方法减轻它们对性能的影响。
您可以将不需要 Session 的内容（如帮助屏幕，访问者区域等等）移到另一个关闭了 Session 的 ASP 应用程序中。您可以逐页提示 ASP，您不再需要该页面上的 Session 对象，使用以下放在 ASP 页面最上面的指令：
<% @EnableSessionState=False %>
使用这一指令有一个很好的理由是，这些 Session 在框架集方面存在一个有意思的问题。ASP 保证任何时候 Session 只有一个请求执行。这样就确保如果浏览器为一个用户请求多个页面，一次只有一个 ASP 请求接触 Session，这样就避免了当访问 Session 对象时发生的多线程问题。很遗憾，一个框架集中的所有页面将以串行方式显示，一个接一个，而不是同时显示。用户可能必须等候很长时间，才能看到所有的框架。该故事的寓意：如果某些框架集页面不依靠 Session，一定要使用 @EnableSessionState=False 指令告诉 ASP。
有许多管理 Session 状态的方法，可替代 Session 对象的使用。对于少量的状态（少于 4 KB），我们通常建议使用 Cookies、QueryString 变量和隐式变量。对于更大数据量，如购物小车，后端数据库是最适合的选择。有关 Web 服务器群中状态管理技术的文章很多。有关详细信息，请参见 Session 状态参考资料。
技巧 7: 将代码封装在 COM 对象中
如果您有许多 VBScript 或 JScript，您可以经常将代码移到编译的 COM 对象中，从而可改善性能。编译的代码通常比解释的代码运行得更快。编译的 COM 对象可以通过“早绑定”访问其它 COM 对象，与脚本使用的“晚绑定”相比，“早绑定”是调用 COM 对象的更有效方法。
将代码封装在 COM 对象中还有一些优点（除性能之外）：
COM 对象有利于将表示逻辑与业务逻辑分开。
COM 对象可以保证代码重复使用。
许多开发人员发现以 VB、C++ 或 Visual J++ 编写的代码比 ASP 更容易调试。
COM 对象也有缺点，包括初始开发时间和需要不同的程序设计技巧。注意封装少量的 ASP 可能引起性能下降，而不会得到性能改进。这种情况通常在少量的 ASP 代码被封装进 COM 对象时发生。在这种情况下，创建和调用 COM 对象的系统开销超过了编译的代码的优点。应反复地试验，以确定什么样的 ASP 脚本和 COM 对象代码的组合产生最好的性能。注意，与 Microsoft Windows NT? 4.0/IIS 4.0 相比，Windows 2000/IIS 5.0 中在脚本和 ADO 性能方面有了很大的改进。因此，随着 IIS 5.0 的推出，编译代码比 ASP 代码的性能优势有所降低。
有关在 ASP 中使用 COM 的优点和缺点的详细讨论，参见 ASP Component Guidelines and Programming Distributed Applications with and Microsoft Visual Basic 6.0。如果您部署 COM 组件，以负荷对它们进行测试特别重要。事实上，理所当然应对所有的 ASP 应用程序进行负荷测试。
Set rs = Server.CreateObject(?ADODB.RecordSet?)
rs.CursorLocation = adUseClient ' step 1
' Populate the recordset with data
rs.Open strQuery, strProv
' Now disconnect the recordset from the data provider and data source
rs.ActiveConnection = Nothing ' step 2
有关连接池的更详细信息，可以在 ADO 和 SQL Server 参考资料中找到。
技巧 6：合理地使用 Session 对象
既然我们已经讨论了缓存在 Application 和 Session 中的优点，现在开始讨论避免使用 Session 对象的问题。正如下面所讨论的，当与忙的站点一起使用时，Session 有几个缺点。“忙”的意思一般是指一秒钟要求几百页面或成千上万同时用户的站点。这个技巧对于必须水平扩展的站点 - 即，那些利用多台服务器以处理负载或实现容错的站点 - 甚至更重要。对于较小的站点，诸如 Intranet 站点，要想实现 Session 带来的方，必然增大系统开销。
简言之，ASP 自动为每个访问 Web 服务器的用户创建一个 Session。每个 Session 大约需要 10 KB 的内存开销（最主要的是数据存储在 Session 中），这就使所有的请求都减慢。在配置的超时时段（通常是 20 分钟）结束以前，Session 一直保留有效。
Session 的最大的问题不是性能，而是可扩展性。Session 不能跨越几台 Web 服务器，一旦在一台服务器上创建 Session，其数据就留在那儿。这就意味着如果您在一个 Web 服务器群使用 Session，您必须设计一个策略，将每个用户请求始终发到用户 Session 所在的那台服务器上。这被称为将用户“粘”在 Web 服务器上。术语“粘性会话”就是从这里派生而来的。如果 Web 服务器崩溃，被“粘住的”用户将丢失他们的会话状态，因为会话不是粘到磁盘上。
实现粘性会话的策略包括硬件和软件解决方案。诸如 Windows 2000 Advanced Server 中的网络负载平衡和 Cisco 的 Local Director 之类的解决方案都可以实现粘性会话，代价是要损失一定程度的可扩展性。这些解决方案是不完善的。不建议此时部署您自己的软件解决方案（我们过去常常使用 ISAPI 筛选器和 URL 转换等等）。
Application 对象也不跨越多台服务器，如果您必须跨越 Web 服务器群共享和更新 Application 数据，您必须使用后端数据库。但是，只读 Application 数据在 Web 服务器群中仍是有用的。
如果只是因为要增加运行时间（处理故障转移和服务器维护），大多数关键任务站点至少需部署两台 Web 服务器。因此，在设计关键任务应用程序时，必须实现“粘性会话”，或干脆避免使用 Session，以及任何其它将用户状态存储在单个 Web 服务器上的状态管理技术。
如果您不使用 Session，一定要将它们关闭。您可以通过 Internet Services Manager，为应用程序执行此操作（参见 ISM 文档）。如果您决定使用 Session，您可以采用一些方法减轻它们对性能的影响。
您可以将不需要 Session 的内容（如帮助屏幕，访问者区域等等）移到另一个关闭了 Session 的 ASP 应用程序中。您可以逐页提示 ASP，您不再需要该页面上的 Session 对象，使用以下放在 ASP 页面最上面的指令：
<% @EnableSessionState=False %>
使用这一指令有一个很好的理由是，这些 Session 在框架集方面存在一个有意思的问题。ASP 保证任何时候 Session 只有一个请求执行。这样就确保如果浏览器为一个用户请求多个页面，一次只有一个 ASP 请求接触 Session，这样就避免了当访问 Session 对象时发生的多线程问题。很遗憾，一个框架集中的所有页面将以串行方式显示，一个接一个，而不是同时显示。用户可能必须等候很长时间，才能看到所有的框架。该故事的寓意：如果某些框架集页面不依靠 Session，一定要使用 @EnableSessionState=False 指令告诉 ASP。
有许多管理 Session 状态的方法，可替代 Session 对象的使用。对于少量的状态（少于 4 KB），我们通常建议使用 Cookies、QueryString 变量和隐式变量。对于更大数据量，如购物小车，后端数据库是最适合的选择。有关 Web 服务器群中状态管理技术的文章很多。有关详细信息，请参见 Session 状态参考资料。
技巧 7: 将代码封装在 COM 对象中
如果您有许多 VBScript 或 JScript，您可以经常将代码移到编译的 COM 对象中，从而可改善性能。编译的代码通常比解释的代码运行得更快。编译的 COM 对象可以通过“早绑定”访问其它 COM 对象，与脚本使用的“晚绑定”相比，“早绑定”是调用 COM 对象的更有效方法。
将代码封装在 COM 对象中还有一些优点（除性能之外）：
COM 对象有利于将表示逻辑与业务逻辑分开。
COM 对象可以保证代码重复使用。
许多开发人员发现以 VB、C++ 或 Visual J++ 编写的代码比 ASP 更容易调试。
COM 对象也有缺点，包括初始开发时间和需要不同的程序设计技巧。注意封装少量的 ASP 可能引起性能下降，而不会得到性能改进。这种情况通常在少量的 ASP 代码被封装进 COM 对象时发生。在这种情况下，创建和调用 COM 对象的系统开销超过了编译的代码的优点。应反复地试验，以确定什么样的 ASP 脚本和 COM 对象代码的组合产生最好的性能。注意，与 Microsoft Windows NT? 4.0/IIS 4.0 相比，Windows 2000/IIS 5.0 中在脚本和 ADO 性能方面有了很大的改进。因此，随着 IIS 5.0 的推出，编译代码比 ASP 代码的性能优势有所降低。
有关在 ASP 中使用 COM 的优点和缺点的详细讨论，参见 ASP Component Guidelines and Programming Distributed Applications with and Microsoft Visual Basic 6.0。如果您部署 COM 组件，以负荷对它们进行测试特别重要。事实上，理所当然应对所有的 ASP 应用程序进行负荷测试。
