改进性能和样式的 24个 ASP 技巧第1/2页(8)

由于被连接的记录集中存储有对数据库连接的引用，所以，不应当在 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 矫直对方案进行检查）。