写对象，请不要将它们缓存在 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 '' 第 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 服务器；一
