旦在一个服务器上创建了 Session，它的数据就保持在那里。这意味着，如果您在 Web 领域中使用 Sessions，您将不得不为每个用户的请求设计一种策略，以便始终将这些请求引向用户的 Session 所在的服务器。这被称为将用户"粘"到 Web 服务器上。术语"粘性会话"即来源于此。由于 Session 没有保持到磁盘上，所以，当 Web 服务器崩溃时，被"粘住"的用户将丢失他们的 Sessions 状态。
用于实施粘性会话的策略包括硬件和软件解决方案。如 Windows 2000 Advanced Server 中的网络负载平衡解决方案和 Cisco 公司的"本地指向器"解决方案可以实施粘性会话，但以牺牲一些可伸缩性为代价。这些解决方案并不完美。我们不主张您现在全盘推翻您的软件解决方案（我们过去常用 ISAPI 筛选器和 URL 矫直对方案进行检查）。
Application 对象也不能跨越服务器；如果您需要在 Web 领域内共享并更新 Application 数据，则需要使用后端数据库。但只读的 Application 数据在 Web 领域中仍然有用。
如果只是为了增加正常运行时间（用于处理故障转移和服务器维护），大多数执行重要任务的站点将需要部署至少两台 Web 服务器。所以，在设计执行重要任务的应用程序时，您将需要实施"粘性会话"，或者简单地避开 Sessions 以及其他任何在单个 Web 服务器上存储用户状态的状态管理技术。
如果当前没有使用 Sessions，请确保将它们关闭。可以通过"Internet 服务管理器"（请参阅 ISM 文档）来为应用程序执行该操作。如果决定使用 Sessions，可以采取几个方法来将对性能的影响降低到最小。
可以将不需要 Sessions 的内容（如"帮助"屏幕、访问者区域等）移动到关闭了 Sessions 的、单独的 ASP 应用程序中。可以逐页提示 ASP：在给定的页中您不需要 Session 对象；使用位于 ASP 页顶端的如下指令：
<% @EnableSessionState=False %>
使用该指令的一个很好的原因是，Session 给框架集带来了有趣的问题。ASP 保证任何时候只执行一个来自 Session 的请求。这样可以确保如果浏览器为一个用户请求了多个页时，在每一时刻只有一个 ASP 请求将进入 Session；这就避免了在访问 Session 对象时出现多线程问题。遗憾的是，结果，框架集中的所有页均被以串行化方式绘制，一个接一个地，而不是同时地。这样，用户可能不得不等待很长时间才能得到所有框架内容。这意味着：如果某些框架页不信任 Session，一定要使用
@EnableSessionState=False
指令告诉 ASP。
作为使用 Session 对象的替代方式，有很多方法可以用来管理 Session 状态。对于状态数量较小的情况（不到 4 KB），通常建议使用 Cookies、QueryString 变量和隐藏形式的变量。对于较大数量的数据，如购物推车，则使用后端数据库是最合适的选择。关于在 Web 服务器领域中的状态管理技术已经有很多资料。详细信息，请参阅 会话状态（英文）。
技巧 7：在 COM 对象中封装代码
如果您有很多 VBScript 或 JScript，那么您可以通过把代码移动到已编译的 COM 对象来经常改进它们的性能。已编译的代码通常比被解释代码运行得更快。已编译的 COM 对象可以通过"早期绑定"访问其他 COM 对象，这种调用 COM 对象方法的手段，比脚本所使用的"后期绑定"更有效。
将代码封装在 COM 对象种有如下好处（超越性能）：
COM 对象是将表达逻辑与业务逻辑分隔开来的好办法。
COM 对象启用了代码重用。
很多开发商发现，用 VB、C++ 或 Visual J++ 书写的代码，比 ASP 更容易调试。
COM 对象有一些缺点，包括初始开发时间以及需要不同的编程技巧。需要警告您的是，封装"少"量的 ASP 可能会导致性能降低，而不是提高。通常，在少量 ASP 代码封装到 COM 对象时出现这样的情况。这时候，创建和调用 COM 对象的开销，超过了已
