ASP性能优化28条守则---[6] 合理地使用 Session 对象

技巧 6：合理地使用 Session 对象
既然我们已经讨论了缓存在 Application 和 Session 中的优点，现在开始讨论避免使用 Session 对象的问题。正如下面所讨论的，当与忙的站点一起使用时，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 服务器群中仍是有用的。

如果只是因为要增加运行时间（处理故障转移和服务器维护），大多数关键任务站点至少需部署两台 Web 服务器。因此，在设计关键任务应用程序时，必须实现“粘性会话”，或干脆避免使用 Session，以及任何其它将用户状态存储在单个 Web 服务器上的状态管理技术。

如果您不使用 Session，一定要将它们关闭。您可以通过 Internet Services Manager，为应用程序执行此操作（参见 ISM 文档）。如果您决定使用 Session，您可以采用一些方法减轻它们对性能的影响。

您可以将不需要 Session 的内容（如帮助屏幕，访问者区域等等）移到另一个关闭了 Session 的 ASP 应用程序中。您可以逐页提示 ASP，您不再需要该页面上的 Session 对象，使用以下放在 ASP 页面最上面的指令：

<% @EnableSessionState=False %>

使用这一指令有一个很好的理由是，这些 Session 在框架集方面存在一个有意思的问题。ASP 保证任何时候 Session 只有一个请求执行。这样就确保如果浏览器为一个用户请求多个页面，一次只有一个 ASP 请求接触 Session，这样就避免了当访问 Session 对象时发生的多线程问题。很遗憾，一个框架集中的所有页面将以串行方式显示，一个接一个，而不是同时显示。用户可能必须等候很长时间，才能看到所有的框架。该故事的寓意：如果某些框架集页面不依靠 Session，一定要使用 @EnableSessionState=False 指令告诉 ASP。

有许多管理 Session 状态的方法，可替代 Session 对象的使用。对于少量的状态（少于 4 KB），我们通常建议使用 Cookies、QueryString 变量和隐式变量。对于更大数据量，如购物小车，后端数据库是最适合的选择。有关 Web 服务器群中状态管理技术的文章很多。有关详细信息，请参见 Session 状态参考资料。