技巧 6：妙用 Session 对象

在肯定了在 Applications 和 Sessions 中缓存的优点之后，我们建议您避免使用 Session 对象。下面将会谈到，当用于忙碌站点时，Sessions 有几个缺点。所谓忙碌，通常是指站点每秒请求数百页或同时有数千个用户。该技巧对于必须进行水平扩展的站点，即那些利用多个服务器来适应负载或执行容错功能的站点来说，更加重要。对于较小的站点，如 intranet 站点，Sessions 的便利，与开销相比也是值得的。

为了翻新，ASP 自动为每个访问 Web 服务器的用户创建一个 Session。每个 Session 有大约 10 KB 内存开销（在存储在 Session 中的任何数据中是最高的），并使所有的请求都慢了一点。Session 一直保持活动状态，直到达到可配置的超时（通常 20 分钟）为止。

Session 最大的问题不是性能而是可伸缩性。Session 不能跨越 Web 服务器；一旦在一个服务器上创建了 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 对象的开销，超过了已编译代码的好处。至于 ASP 脚本和 COM 对象代码怎样合并才能产生最佳性能还有待测试。注意，与 Windows NT(R) 4.0/IIS 4.0 相比，Microsoft 已经在 Windows 2000/IIS 5.0 中极大地提高了脚本和 ADO 性能。这样，已编译代码对 ASP 代码的性能优势已经随着 IIS 5.0 的引入而降低。

评论 (0) All

登陆 还没注册？