个可用的工作者线程来处理。如果 Session 被锁定于一个线程，那么请求必须等到其相关的线程可用为止。这里有一个类比，也许会有所帮助：您去一家超级市场，挑选了一些商品，并在 #_3 收款台付款。其后，每当您在那家超级市场为商品付款时，您总是必须在 #_3 收款台付款，即使其它收款台前排队的人较少或者没有人排队，也是如此。
将非敏捷的组件存储在 Application 作用域对性能的影响甚至更坏。ASP 必须创建一个特殊的线程运行存储在 Application 作用域中的非敏捷组件。这会有两个结果：所有调用都必须汇集到此线程，且所有调用都排成长队。“汇集”的意思是参数必须存储在内存的共享区域；执行一个开销很大的到特殊线程的上下文切换；执行组件的方法；将结果汇集到共享区域；执行另一个开销很大的上下文切换，将控制返回到原始的线程。“串行化”意思是指每次只运行一个方法。两个不同的 ASP 工作者线程不能同时在共享组件上执行多个方法。这样就杜绝了并发性，特别是在多处理器计算机上。更糟的是，所有非敏捷的 Application 作用域的组件共享一个线程（主机 STA），因此串行化的影响甚至更显著。
如之奈何？下面是一些一般的规则。如果您使用 Visual Basic (6.0) 或更早版本编写对象，那么不要将它们缓存在 Application 或 Session 对象中。如果您不知道对象的线程模型，不要缓存它。不要缓存非敏捷的对象，而应在每个页面创建和释放它们。对象直接在 ASP 工作者线程上运行，因此没有汇集或串行化。如果 COM 对象在 IIS 服务器上运行，且如果它们不花长时间初始化和删除，性能尚可。注意单线程对象不应该这样使用。小心 - VB 可创建单线程对象！如果您必须这样使用单线程对象（如 Microsoft Excel 电子表格），别指望会有很高的吞吐量。
当 ADO 被标记为自由线程，ADO 记录集可以安全地缓存。要将 ADO 标记为自由线程，使用 Makfre15.bat 文件，该文件通常位于目录 \\Program Files\Common\System\ADO 中。
警告 如果您使用 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 ' 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 对象也不跨越
将非敏捷的组件存储在 Application 作用域对性能的影响甚至更坏。ASP 必须创建一个特殊的线程运行存储在 Application 作用域中的非敏捷组件。这会有两个结果：所有调用都必须汇集到此线程，且所有调用都排成长队。“汇集”的意思是参数必须存储在内存的共享区域；执行一个开销很大的到特殊线程的上下文切换；执行组件的方法；将结果汇集到共享区域；执行另一个开销很大的上下文切换，将控制返回到原始的线程。“串行化”意思是指每次只运行一个方法。两个不同的 ASP 工作者线程不能同时在共享组件上执行多个方法。这样就杜绝了并发性，特别是在多处理器计算机上。更糟的是，所有非敏捷的 Application 作用域的组件共享一个线程（主机 STA），因此串行化的影响甚至更显著。
如之奈何？下面是一些一般的规则。如果您使用 Visual Basic (6.0) 或更早版本编写对象，那么不要将它们缓存在 Application 或 Session 对象中。如果您不知道对象的线程模型，不要缓存它。不要缓存非敏捷的对象，而应在每个页面创建和释放它们。对象直接在 ASP 工作者线程上运行，因此没有汇集或串行化。如果 COM 对象在 IIS 服务器上运行，且如果它们不花长时间初始化和删除，性能尚可。注意单线程对象不应该这样使用。小心 - VB 可创建单线程对象！如果您必须这样使用单线程对象（如 Microsoft Excel 电子表格），别指望会有很高的吞吐量。
当 ADO 被标记为自由线程，ADO 记录集可以安全地缓存。要将 ADO 标记为自由线程，使用 Makfre15.bat 文件，该文件通常位于目录 \\Program Files\Common\System\ADO 中。
警告 如果您使用 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 ' 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 对象也不跨越
相关文章
 我来说两句 |
对此文章发表了评论 |
评论列表 （最新 评论仅限网友观点！）
推荐文章
