微软建议的ASP性能优化28条守则
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 或更低版本编写的对象）当存储在 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 作用域中），您可以在配置数据库中将 AspTrackThreadingModel 设置为 True。不建议更改 AspTrackThreadingModel。
如果您想将以 Server.CreateObject 创建的非敏捷的组件存储在 Application 对象中，IIS 5.0 将出现一个错误。您可以在 Global.asa 中使用 <object runat=server scope=application > 避免这一错误，但不建议这样做，因为这会导致汇集和串行化，关于这一点将在下面讲述。
如果您缓存非敏捷的组件会出现什么毛病？缓存在 Session 对象中的非敏捷的组件将 Session 锁定于 ASP 工作者线程。ASP 维护一个工作者线程池来处理请求。通常情况下，一个新请求总是由第一个可用的工作者线程来处理。如果 Session 被锁定于一个线程，那么请求必须等到其相关的线程可用为止。这里有一个类比，也许会有所帮助：您去一家超级市场，挑选了一些商品，并在 #_3 收款台付款。其后，每当您在那家超级市场为商品付款时，您总是必须在 #_3 收款台付款，即使其它收款台前排队的人较少或者没有人排队，也是如此。
将非敏捷的组件存储在 Application 作用域对性能的影响甚至更坏。ASP 必须创建一个特殊的线程运行存储在 Application 作用域中的非敏捷组件。这会有两个结果：所有调用都必须汇集到此线程，且所有调用都排成长队。“汇集”的意思是参数必须存储在内存的共享区域;执行一个开销很大的到特殊
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 或更低版本编写的对象）当存储在 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 作用域中），您可以在配置数据库中将 AspTrackThreadingModel 设置为 True。不建议更改 AspTrackThreadingModel。
如果您想将以 Server.CreateObject 创建的非敏捷的组件存储在 Application 对象中，IIS 5.0 将出现一个错误。您可以在 Global.asa 中使用 <object runat=server scope=application > 避免这一错误，但不建议这样做，因为这会导致汇集和串行化，关于这一点将在下面讲述。
如果您缓存非敏捷的组件会出现什么毛病？缓存在 Session 对象中的非敏捷的组件将 Session 锁定于 ASP 工作者线程。ASP 维护一个工作者线程池来处理请求。通常情况下，一个新请求总是由第一个可用的工作者线程来处理。如果 Session 被锁定于一个线程，那么请求必须等到其相关的线程可用为止。这里有一个类比，也许会有所帮助：您去一家超级市场，挑选了一些商品，并在 #_3 收款台付款。其后，每当您在那家超级市场为商品付款时，您总是必须在 #_3 收款台付款，即使其它收款台前排队的人较少或者没有人排队，也是如此。
将非敏捷的组件存储在 Application 作用域对性能的影响甚至更坏。ASP 必须创建一个特殊的线程运行存储在 Application 作用域中的非敏捷组件。这会有两个结果：所有调用都必须汇集到此线程，且所有调用都排成长队。“汇集”的意思是参数必须存储在内存的共享区域;执行一个开销很大的到特殊