您现在的位置： 
技巧 1：将经常使用的数据缓存在 Web 服务器上
典型的 ASP 页从后端数据存储中检索数据，然后将结果转换成超文本标记语言 (HTML)。无论数据库的速度如何，从内存中检索数据总要比从后端数据存储中检索数据快得多。从本地硬盘读取数据通常也比从数据库中检索数据更快。因此，通常可以将数据缓存在 Web 服务器上（存储在内存或磁盘中），来提高性能。 缓存是传统的以空间换取时间的做法。如果您缓存的内容正确，那么您可以看到性能会有显著的提高。为使缓存有效，必须保存那些经常重复使用的数据，且要重新计算这些数据需要（适度）大的开销。如果缓存的都是些陈旧的数据，就会造成内存浪费。 不经常发生改变的数据是很好的缓存候选数据，因为您不必担心随着时间的迁移该数据与数据库同步的问题。组合框列表、引用表、DHTML 碎片、扩展标记语言 (XML) 字符串、菜单项和站点配置变量（包括数据源名称 (DSN)、Internet 协议 (IP) 地址和 Web 路径）都是很好的缓存候选内容。注意您可以缓存数据的“表示”，而不缓存数据本身。如果 ASP 页很少更改，且缓存的开销也很大（例如，整个产品目录），则应考虑事先产生 HTML，而不是在响应每个请求时重新显示。 应将数据缓存在哪里，有哪些缓存策略？通常，数据缓存在 Web 服务器的内存或磁盘中。
技巧 2: 将经常使用的数据缓存在 Application 或 Session 对象中
ASP Application 和 Session 对象为将数据缓存在内存中提供了方便的容器。您可以将数据指派到 Application 和 Session 对象中，这些数据在 HTTP 调用之间保留在内存中。Session 数据是按每个用户分别存储的，而Application 数据则在所有用户之间共享。 什么时候将数据装载到 Application 或 Session 中呢？通常，数据是在启动Application 或 Session 时装载。要在 Application 或 Session 启动过程中装载数据，应将适当的代码分别添加到Application_OnStart() 或 Session_OnStart() 中。这些函数应在 Global.asa 中，如果没有，则可以添加这些函数。还可以在第一次需要时装函数应在 Global.asa 中，如果没有，则可以添加这些函数。还可以在第一次需要时装载该数据。为此，在 ASP 页中添加一些代码（或编写一个可重复使用的脚本函数），以检查数据是否存在，如果不存在，就装载数据。这是一个传统的性能技术，称为“惰性计算” - 在您知道需要某一个值以前不计算该值。例如： 可以为所需要的每个数据块编写类似的函数。 应以什么格式存储数据？可以存储任何变体类型，因为所有脚本变量都是变体型。例如，您可以存储字符串、整数或数组。通常，您将以这些变量类型之一存储 ADO 记录集的内容。要从 ADO 记录集获取数据，您可以手工将数据复制到 VBScript 变量，一次一个字段。使用一个 ADO 记录集持久函数 GetRows()、GetString() 或Save()(ADO 2.5)，可加快速度且更容易一些。 在适当的条件下，可以将 ADO 记录集本身缓存在 Application 或 Session 作用域中。有两个警告：
必须将 ADO 标记为自由线程
必须使用断开连接的记录集。
如果不能保证满足这两个要求，则不要缓存 ADO 记录集。在下面的“非敏捷组件”和“不要缓存连接”技巧中，我们将讨论将 COM 对象存储在 Application 或 Session 作用域中的危险性。 当您将数据存储在 Application 或 Session 作用域时，数据将保留在那里，直到您以编程方式改变它、Session 过期或 Web 应用程序重新启动为止。如果数据需要更新怎么办？要手工强制对 Application 数据进行更新，您可以访问只有管理员才可访问的 ASP 页来更新数据。或者，您可以通过函数定期自动刷新数据。下面例子存储带有缓存数据的时间戳，并隔一段时间后刷新数据。 Session[/b] 或 Application对象中缓存大的数组不是一个好的做法。在访问数组的任何元素之前，脚本语言的语法要求必须临时复制整个数组。数组能快速查寻和存储在内存中是邻近的关键数据对。索引一个词典比索引一个数组要慢得多。应针对您的实际情况，选择提供最佳性能的数据结构。
技巧 3：将数据和 HTML 缓存在 Web 服务器的磁盘上
有时，数据可能太多，无法都缓存在内存中。“太多”只是一个说法，这要看您想消耗多少内存，以及需缓存的项目数和检索这些项目的频率。在任何情况下，如果数据太多多少内存，以及需缓存的项目数和检索这些项目的频率。在任何情况下，如果数据太多而无法都缓存在内存中，则考虑将数据以文本或 XML 文件缓存在 Web 服务器的硬盘上。可以同时将数据缓存在磁盘和内存中，为您的站点建立最适宜的缓存策略。 注意当测量单个 ASP 页的性能时，检索磁盘上的数据可能不一定要比从数据库检索数据更快。但缓存会降低数据库和网络上的负载。在高负载的情况下，这样做可大大改善总体吞吐量。当缓存开销很大的查询结果（如多表联接或复合存储过程）或大的结果集时，这是非常有效的。与往常一样，要测试一下几种方案的优劣。 ASP 和 COM 提供一些建立基于磁盘的缓存方案的工具。ADO 记录集 Save() 和 Open() 函数保存和装载磁盘中的记录集。可以使用这些方法重新编写上面 Application 数据缓存技巧中的代码示例，用文件的 Save() 代替写到Application 对象中的代码。 有一些其它组件可以用于文件：
Scripting.FileSystemObject 可使您创建、读和写文件。
与 Internet Explorer 一起提供的 Microsoft® XML 解析器 (MSXML) 支持保存和装载 XML 文档。
LookupTable 对象（例如，用在 MSN 上）是从磁盘装载简单列表的最好选择。最后，应考虑将数据的表示缓存在磁盘上，而不是数据本身。预先转换的 HTML 可以用.htm 或 .asp 文件存储在磁盘上，超级链接可以直接指向这些文件。可以使用商用工具，如 XBuilder，或 Microsoft® SQL Server™ Internet 发布功能将产生HTML 的过程自动化。或者，您可以将 HTML 代码片断放在 .asp 文件中。还可以使用FileSystemObject 从磁盘读取 HTML 文件，或使用 XML 尽早转换。
技巧 4：避免将非敏捷的组件缓存在 Application 或 Session 对象中
尽管将数据缓存在 Application 或 Session 对象中是一个好的做法，但缓存 COM 对象却有严重的陷阱。通常，人们倾向于将经常使用的 COM 对象缓存到 Application 或 Session 对象中。很遗憾，许多 COM 对象（包括所有以 Visual Basic 6.0 或更低版本ession 对象中。很遗憾，许多 COM 对象（包括所有以 Visual Basic 6.0 或更低版本编写的对象）当存储在 Application 或 Session 对象时，会引起严重的瓶颈。 具体来讲，当任何不敏捷的组件缓存在 Session 或 Application 对象时，将引起性能瓶颈。敏捷的组件是被标记为 ThreadingModel=Both 的组件，它聚集 Free-threaded marshaler (FTM)；或被标记为ThreadingModel=Neutral 的组件。（Neutral 模型是 Windows® 2000 和 COM+ 的新增模型。） 下列组件不是敏捷的：
自由线程的组件（除非它们聚集 FTM）。
单元线程组件。
单线程组件。
配置的组件（Microsoft Transaction Server (MTS)/COM+ 库和服务器程序包/应用程序）不是敏捷的，除非它们是 Neutral 线程。单元线程组件和其它非敏捷的组件在页作用域内是最适合的（即，它们在单个 ASP 页上创建和销毁）。 在 IIS 4.0 中，被标记为ThreadingModel=Both 的组件被认为是敏捷的。在 IIS 5.0 中，只有这一点还不够。组件必须不仅被标记 Both，还必须聚集 FTM。有关敏捷性的文章讲述了如何使以 Active Template Library 编写的 C++ 组件聚集 FTM。要注意如果组件缓存界面指针，那么那些指针本身必须是敏捷的，或必须存储在 COM 共用界面表 (GIT) 中。如果您不能重新编译 Both 线程组件以聚集 FTM，那么您可以将组件标记为 ThreadingModel=Neutral。或者，如果您不想让 IIS 执行敏捷性检查（因此，您可以允许非敏捷的组件存储在Application 或 Session 作用域中），您可以在配置数据库中将 AspTrackThreading Model 设置为 True。不建议更改 AspTrackThreadingModel。 如果您想将以Server.CreateObject 创建的非敏捷的组件存储在 Application 对象中，IIS 5.0 将出现一个错误。您可以在Global.asa 中使用 避免这一错误，但不建议这样做，因为这会导致汇集和串行化，关于这一点将在下面讲述。 如果您缓存非敏捷的组件会出现什么毛病？缓集和串行化，关于这一点将在下面讲述。 如果您缓存非敏捷的组件会出现什么毛病？缓
存在 Session 对象中的非敏捷的组件将 Session 锁定于 ASP 工作者线程。ASP 维护一个工作者线程池来处理请求。通常情况下，一个新请求总是由第一个可用的工作者线程来处理。如果 Session 被锁定于一个线程，那么请求必须等到其相关的线程可用为止。
将非敏捷的组件存储在Application 作用域对性能的影响甚至更坏。ASP 必须创建一个特殊的线程运行存储在
Application 作用域中的非敏捷组件。这会有两个结果：所有调用都必须汇集到此线程，且所有调用都排成长队。“汇集”的意思是参数必须存储在内存的共享区域；执行一个开销很大的到特殊线程的上下文切换；执行组件的方法；将结果汇集到共享区域；执行另一个开销很大的上下文切换，将控制返回到原始的线程。“串行化”意思是指每次只运行一个方法。两个不同的 ASP 工作者线程不能同时在共享组件上执行多个方法。这样就杜绝了并发性，特别是在多处理器计算机上。更糟的是，所有非敏捷的 Application 作用域的组件共享一个线程（主机 STA），因此串行化的影响甚至更显著。 如之奈何？下面是一些一般的规则。如果您使用 Visual Basic (6.0) 或更早版本编写对象，那么不要将它们缓存在 Application 或 Session 对象中。如果您不知道对象的线程模型，不要缓存它。不要缓存非敏捷的对象，而应在每个页面创建和释放它们。对象直接在 ASP 工作者线程上运行，因此没有汇集或串行化。如果 COM 对象在 IIS 服务器上运行，且如果它们不花长时间初始化和删除，性能尚可。注意单线程对象不应该这样使用。小心 - VB 可创建单线程对象！如果您必须这样使用单线程对象（如 Microsoft Excel 电子表格），别指望会有很高的吞吐量。当 ADO 被标记为自由线程，ADO 记录集可以安全地缓存。要将 ADO 标记为自由线程，使用 Makfre15.bat 文件，该文件通常位于以安全地缓存。要将 ADO 标记为自由线程，使用 Makfre15.bat 文件，该文件通常位于目录 \Program FilesCommonSystemADO 中。
警告 如果您使用 Microsoft Access作为数据库，不应将 ADO 标记为自由线程的。ADO 记录集也必须切断连接。一般来说，如果您不能控制站点中的 ADO 配置，最好不要缓存记录集。 词典组件也是敏捷的对象。LookupTable 从数据文件中装载其数据，可用于组合框数据和配置信息。Duwa mish 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 对象中。但是，您可以安全地缓存断开连接的记录集，它们不保存到其数据连接的引用。
技巧 6：合理地使用 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 服务器群中仍是有用的。 如果只是因为要增加运行时间只读 Application 数据在 Web 服务器群中仍是有用的。 如果只是因为要增加运行时间（处理故障转移和服务器维护），大多数关键任务站点至少需部署两台 Web 服务器。因此，在设计关键任务应用程序时，必须实现“粘性会话”，或干脆避免使用 Session，以及任何其它将用户状态存储在单个 Web 服务器上的状态管理技术。 如果您不使用 Session，一定要将它们关闭。您可以通过 Internet Services Manager，为应用程序执行此操作。如果您决定使用 Session，您可以采用一些方法减轻它们对性能的影响。 您可以将不需要 Session 的内容（如帮助屏幕，访问者区域等等）移到另一个关闭了 Session 的 ASP 应用程序中。您可以逐页提示 ASP，您不再需要该页面上的 Session 对象，使用以下放在 ASP 页面最上面的指令： 使用这一指令有一个很好的理由是，这些 Session 在框架集方面存在一个有意思的问题。ASP 保证任何时候Session 只有一个请求执行。这样就确保如果浏览器为一个用户请求多个页面，一次只有一个 ASP 请求接触 Session，这样就避免了当访问 Session 对象时发生的多线程问题。很遗憾，一个框架集中的所有页面将以串行方式显示，一个接一个，而不是同时显示。用户可能必须等候很长时间，才能看到所有的框架。该故事的寓意：如果某些框架集页面不依靠 Session，一定要使用 EnableSessionState=False 指令告诉 ASP。
有许多管理 Session 状态的方法，可替代 Session 对象的使用。对于少量的状态（少于4 KB），我们通常建议使用 Cookies、QueryString 变量和隐式变量。
技巧 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 代码的性能优势有所降低。如果您部署 COM 组件，以负荷对它们进行测试特别重要。事实上，理所当然应对所有的 ASP 应用程序进行负荷测试。
技巧 8：迟一点获得资源，早一点释放资源
这里是一个小技巧供您参考。一般来说，最好迟一点获得资源，早一点释放资源。这适用于 COM 对象以及文件句柄和其它资源。这种优化方法主要用于 ADO 连接和记录集。当您使用完记录集，比方说在显示一个表及其数据之后，应立即释放它，而不是等到页面结束时再释放。将 VBScript 变量设置为Nothing 是最好的做法。不要让记录集超出作用域之外。而且，要释放任何相关的 Command 或 Connection 对象（在将记录集或连接设置为 = Nothing 之前，不要忘记调用Close()）。这会缩短数据库必须为您准备资源的时间，并尽快释放数据库到连接池的连接。
典型的 ASP 页从后端数据存储中检索数据，然后将结果转换成超文本标记语言 (HTML)。无论数据库的速度如何，从内存中检索数据总要比从后端数据存储中检索数据快得多。从本地硬盘读取数据通常也比从数据库中检索数据更快。因此，通常可以将数据缓存在 Web 服务器上（存储在内存或磁盘中），来提高性能。 缓存是传统的以空间换取时间的做法。如果您缓存的内容正确，那么您可以看到性能会有显著的提高。为使缓存有效，必须保存那些经常重复使用的数据，且要重新计算这些数据需要（适度）大的开销。如果缓存的都是些陈旧的数据，就会造成内存浪费。 不经常发生改变的数据是很好的缓存候选数据，因为您不必担心随着时间的迁移该数据与数据库同步的问题。组合框列表、引用表、DHTML 碎片、扩展标记语言 (XML) 字符串、菜单项和站点配置变量（包括数据源名称 (DSN)、Internet 协议 (IP) 地址和 Web 路径）都是很好的缓存候选内容。注意您可以缓存数据的“表示”，而不缓存数据本身。如果 ASP 页很少更改，且缓存的开销也很大（例如，整个产品目录），则应考虑事先产生 HTML，而不是在响应每个请求时重新显示。 应将数据缓存在哪里，有哪些缓存策略？通常，数据缓存在 Web 服务器的内存或磁盘中。
技巧 2: 将经常使用的数据缓存在 Application 或 Session 对象中
ASP Application 和 Session 对象为将数据缓存在内存中提供了方便的容器。您可以将数据指派到 Application 和 Session 对象中，这些数据在 HTTP 调用之间保留在内存中。Session 数据是按每个用户分别存储的，而Application 数据则在所有用户之间共享。 什么时候将数据装载到 Application 或 Session 中呢？通常，数据是在启动Application 或 Session 时装载。要在 Application 或 Session 启动过程中装载数据，应将适当的代码分别添加到Application_OnStart() 或 Session_OnStart() 中。这些函数应在 Global.asa 中，如果没有，则可以添加这些函数。还可以在第一次需要时装函数应在 Global.asa 中，如果没有，则可以添加这些函数。还可以在第一次需要时装载该数据。为此，在 ASP 页中添加一些代码（或编写一个可重复使用的脚本函数），以检查数据是否存在，如果不存在，就装载数据。这是一个传统的性能技术，称为“惰性计算” - 在您知道需要某一个值以前不计算该值。例如： 可以为所需要的每个数据块编写类似的函数。 应以什么格式存储数据？可以存储任何变体类型，因为所有脚本变量都是变体型。例如，您可以存储字符串、整数或数组。通常，您将以这些变量类型之一存储 ADO 记录集的内容。要从 ADO 记录集获取数据，您可以手工将数据复制到 VBScript 变量，一次一个字段。使用一个 ADO 记录集持久函数 GetRows()、GetString() 或Save()(ADO 2.5)，可加快速度且更容易一些。 在适当的条件下，可以将 ADO 记录集本身缓存在 Application 或 Session 作用域中。有两个警告：
必须将 ADO 标记为自由线程
必须使用断开连接的记录集。
如果不能保证满足这两个要求，则不要缓存 ADO 记录集。在下面的“非敏捷组件”和“不要缓存连接”技巧中，我们将讨论将 COM 对象存储在 Application 或 Session 作用域中的危险性。 当您将数据存储在 Application 或 Session 作用域时，数据将保留在那里，直到您以编程方式改变它、Session 过期或 Web 应用程序重新启动为止。如果数据需要更新怎么办？要手工强制对 Application 数据进行更新，您可以访问只有管理员才可访问的 ASP 页来更新数据。或者，您可以通过函数定期自动刷新数据。下面例子存储带有缓存数据的时间戳，并隔一段时间后刷新数据。 Session[/b] 或 Application对象中缓存大的数组不是一个好的做法。在访问数组的任何元素之前，脚本语言的语法要求必须临时复制整个数组。数组能快速查寻和存储在内存中是邻近的关键数据对。索引一个词典比索引一个数组要慢得多。应针对您的实际情况，选择提供最佳性能的数据结构。
技巧 3：将数据和 HTML 缓存在 Web 服务器的磁盘上
有时，数据可能太多，无法都缓存在内存中。“太多”只是一个说法，这要看您想消耗多少内存，以及需缓存的项目数和检索这些项目的频率。在任何情况下，如果数据太多多少内存，以及需缓存的项目数和检索这些项目的频率。在任何情况下，如果数据太多而无法都缓存在内存中，则考虑将数据以文本或 XML 文件缓存在 Web 服务器的硬盘上。可以同时将数据缓存在磁盘和内存中，为您的站点建立最适宜的缓存策略。 注意当测量单个 ASP 页的性能时，检索磁盘上的数据可能不一定要比从数据库检索数据更快。但缓存会降低数据库和网络上的负载。在高负载的情况下，这样做可大大改善总体吞吐量。当缓存开销很大的查询结果（如多表联接或复合存储过程）或大的结果集时，这是非常有效的。与往常一样，要测试一下几种方案的优劣。 ASP 和 COM 提供一些建立基于磁盘的缓存方案的工具。ADO 记录集 Save() 和 Open() 函数保存和装载磁盘中的记录集。可以使用这些方法重新编写上面 Application 数据缓存技巧中的代码示例，用文件的 Save() 代替写到Application 对象中的代码。 有一些其它组件可以用于文件：
Scripting.FileSystemObject 可使您创建、读和写文件。
与 Internet Explorer 一起提供的 Microsoft® XML 解析器 (MSXML) 支持保存和装载 XML 文档。
LookupTable 对象（例如，用在 MSN 上）是从磁盘装载简单列表的最好选择。最后，应考虑将数据的表示缓存在磁盘上，而不是数据本身。预先转换的 HTML 可以用.htm 或 .asp 文件存储在磁盘上，超级链接可以直接指向这些文件。可以使用商用工具，如 XBuilder，或 Microsoft® SQL Server™ Internet 发布功能将产生HTML 的过程自动化。或者，您可以将 HTML 代码片断放在 .asp 文件中。还可以使用FileSystemObject 从磁盘读取 HTML 文件，或使用 XML 尽早转换。
技巧 4：避免将非敏捷的组件缓存在 Application 或 Session 对象中
尽管将数据缓存在 Application 或 Session 对象中是一个好的做法，但缓存 COM 对象却有严重的陷阱。通常，人们倾向于将经常使用的 COM 对象缓存到 Application 或 Session 对象中。很遗憾，许多 COM 对象（包括所有以 Visual Basic 6.0 或更低版本ession 对象中。很遗憾，许多 COM 对象（包括所有以 Visual Basic 6.0 或更低版本编写的对象）当存储在 Application 或 Session 对象时，会引起严重的瓶颈。 具体来讲，当任何不敏捷的组件缓存在 Session 或 Application 对象时，将引起性能瓶颈。敏捷的组件是被标记为 ThreadingModel=Both 的组件，它聚集 Free-threaded marshaler (FTM)；或被标记为ThreadingModel=Neutral 的组件。（Neutral 模型是 Windows® 2000 和 COM+ 的新增模型。） 下列组件不是敏捷的：
自由线程的组件（除非它们聚集 FTM）。
单元线程组件。
单线程组件。
配置的组件（Microsoft Transaction Server (MTS)/COM+ 库和服务器程序包/应用程序）不是敏捷的，除非它们是 Neutral 线程。单元线程组件和其它非敏捷的组件在页作用域内是最适合的（即，它们在单个 ASP 页上创建和销毁）。 在 IIS 4.0 中，被标记为ThreadingModel=Both 的组件被认为是敏捷的。在 IIS 5.0 中，只有这一点还不够。组件必须不仅被标记 Both，还必须聚集 FTM。有关敏捷性的文章讲述了如何使以 Active Template Library 编写的 C++ 组件聚集 FTM。要注意如果组件缓存界面指针，那么那些指针本身必须是敏捷的，或必须存储在 COM 共用界面表 (GIT) 中。如果您不能重新编译 Both 线程组件以聚集 FTM，那么您可以将组件标记为 ThreadingModel=Neutral。或者，如果您不想让 IIS 执行敏捷性检查（因此，您可以允许非敏捷的组件存储在Application 或 Session 作用域中），您可以在配置数据库中将 AspTrackThreading Model 设置为 True。不建议更改 AspTrackThreadingModel。 如果您想将以Server.CreateObject 创建的非敏捷的组件存储在 Application 对象中，IIS 5.0 将出现一个错误。您可以在Global.asa 中使用 避免这一错误，但不建议这样做，因为这会导致汇集和串行化，关于这一点将在下面讲述。 如果您缓存非敏捷的组件会出现什么毛病？缓集和串行化，关于这一点将在下面讲述。 如果您缓存非敏捷的组件会出现什么毛病？缓
存在 Session 对象中的非敏捷的组件将 Session 锁定于 ASP 工作者线程。ASP 维护一个工作者线程池来处理请求。通常情况下，一个新请求总是由第一个可用的工作者线程来处理。如果 Session 被锁定于一个线程，那么请求必须等到其相关的线程可用为止。
将非敏捷的组件存储在Application 作用域对性能的影响甚至更坏。ASP 必须创建一个特殊的线程运行存储在
Application 作用域中的非敏捷组件。这会有两个结果：所有调用都必须汇集到此线程，且所有调用都排成长队。“汇集”的意思是参数必须存储在内存的共享区域；执行一个开销很大的到特殊线程的上下文切换；执行组件的方法；将结果汇集到共享区域；执行另一个开销很大的上下文切换，将控制返回到原始的线程。“串行化”意思是指每次只运行一个方法。两个不同的 ASP 工作者线程不能同时在共享组件上执行多个方法。这样就杜绝了并发性，特别是在多处理器计算机上。更糟的是，所有非敏捷的 Application 作用域的组件共享一个线程（主机 STA），因此串行化的影响甚至更显著。 如之奈何？下面是一些一般的规则。如果您使用 Visual Basic (6.0) 或更早版本编写对象，那么不要将它们缓存在 Application 或 Session 对象中。如果您不知道对象的线程模型，不要缓存它。不要缓存非敏捷的对象，而应在每个页面创建和释放它们。对象直接在 ASP 工作者线程上运行，因此没有汇集或串行化。如果 COM 对象在 IIS 服务器上运行，且如果它们不花长时间初始化和删除，性能尚可。注意单线程对象不应该这样使用。小心 - VB 可创建单线程对象！如果您必须这样使用单线程对象（如 Microsoft Excel 电子表格），别指望会有很高的吞吐量。当 ADO 被标记为自由线程，ADO 记录集可以安全地缓存。要将 ADO 标记为自由线程，使用 Makfre15.bat 文件，该文件通常位于以安全地缓存。要将 ADO 标记为自由线程，使用 Makfre15.bat 文件，该文件通常位于目录 \Program FilesCommonSystemADO 中。
警告 如果您使用 Microsoft Access作为数据库，不应将 ADO 标记为自由线程的。ADO 记录集也必须切断连接。一般来说，如果您不能控制站点中的 ADO 配置，最好不要缓存记录集。 词典组件也是敏捷的对象。LookupTable 从数据文件中装载其数据，可用于组合框数据和配置信息。Duwa mish 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 对象中。但是，您可以安全地缓存断开连接的记录集，它们不保存到其数据连接的引用。
技巧 6：合理地使用 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 服务器群中仍是有用的。 如果只是因为要增加运行时间只读 Application 数据在 Web 服务器群中仍是有用的。 如果只是因为要增加运行时间（处理故障转移和服务器维护），大多数关键任务站点至少需部署两台 Web 服务器。因此，在设计关键任务应用程序时，必须实现“粘性会话”，或干脆避免使用 Session，以及任何其它将用户状态存储在单个 Web 服务器上的状态管理技术。 如果您不使用 Session，一定要将它们关闭。您可以通过 Internet Services Manager，为应用程序执行此操作。如果您决定使用 Session，您可以采用一些方法减轻它们对性能的影响。 您可以将不需要 Session 的内容（如帮助屏幕，访问者区域等等）移到另一个关闭了 Session 的 ASP 应用程序中。您可以逐页提示 ASP，您不再需要该页面上的 Session 对象，使用以下放在 ASP 页面最上面的指令： 使用这一指令有一个很好的理由是，这些 Session 在框架集方面存在一个有意思的问题。ASP 保证任何时候Session 只有一个请求执行。这样就确保如果浏览器为一个用户请求多个页面，一次只有一个 ASP 请求接触 Session，这样就避免了当访问 Session 对象时发生的多线程问题。很遗憾，一个框架集中的所有页面将以串行方式显示，一个接一个，而不是同时显示。用户可能必须等候很长时间，才能看到所有的框架。该故事的寓意：如果某些框架集页面不依靠 Session，一定要使用 EnableSessionState=False 指令告诉 ASP。
有许多管理 Session 状态的方法，可替代 Session 对象的使用。对于少量的状态（少于4 KB），我们通常建议使用 Cookies、QueryString 变量和隐式变量。
技巧 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 代码的性能优势有所降低。如果您部署 COM 组件，以负荷对它们进行测试特别重要。事实上，理所当然应对所有的 ASP 应用程序进行负荷测试。
技巧 8：迟一点获得资源，早一点释放资源
这里是一个小技巧供您参考。一般来说，最好迟一点获得资源，早一点释放资源。这适用于 COM 对象以及文件句柄和其它资源。这种优化方法主要用于 ADO 连接和记录集。当您使用完记录集，比方说在显示一个表及其数据之后，应立即释放它，而不是等到页面结束时再释放。将 VBScript 变量设置为Nothing 是最好的做法。不要让记录集超出作用域之外。而且，要释放任何相关的 Command 或 Connection 对象（在将记录集或连接设置为 = Nothing 之前，不要忘记调用Close()）。这会缩短数据库必须为您准备资源的时间，并尽快释放数据库到连接池的连接。
