微软建议的ASP性能优化28条守则
线程的上下文切换;执行组件的方法;将结果汇集到共享区域;执行另一个开销很大的上下文切换，将控制返回到原始的线程。“串行化”意思是指每次只运行一个方法。两个不同的 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 有几个缺点。“忙”的意思一般是指一秒钟要求几百页面或成千上万同时用户的站点。这个技巧对于必须水平扩展的站点 - 即，那些利用多台服务器以处理负载或实现容错的站点
如之奈何？下面是一些一般的规则。如果您使用 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 有几个缺点。“忙”的意思一般是指一秒钟要求几百页面或成千上万同时用户的站点。这个技巧对于必须水平扩展的站点 - 即，那些利用多台服务器以处理负载或实现容错的站点