session 在负载均衡下的内部机制
是从微软英文资料翻译的，可能有很多错，仅仅作参考
我们已经提到了在Application和Session中缓存数据的好处，下面我们将说一些
Session对象的缺点。在繁忙的站点上使用Session有一些不利的地方。繁忙是指
这个站点每秒钟要处理数以百计的页面请求或同时连接数以千计的并发用户。这
个技巧对那些必须要水平伸缩的站点--就是说，这些站点用多个服务器来实现负
载平衡或容错--非常重要。对小的站点，如公司内网，Session相对与他消耗的资
源来说，还是值得一用的。ASP自动为每个访问Web服务器的拥护创建一个Sessio
n对象。每个Session大约消耗10K的资源，并使所有的请求都慢了一点。这个Ses
sion在超时周期内一直存在，这个周期一般是20分钟。对于Session来说最大的问
题不是性能而是伸缩能力。Session不是跨Web服务器的；一旦一个Session在某个
服务器上创建，它的数据都保存在那儿。这意味着如果你要在多个Web服务器环境
中使用Session，你必须设计一套能使用户总是访问它的Session对象所在的Web服
务器的策略；即将一个用户粘到一个Web服务器上。如果Web服务器崩溃，因为Se
ssion不是永久保存在磁盘上的饿，所以全部“粘”在其上的用户的Session状态
都将丢失。实现“粘Session(sticky session)”的策略包括硬件和软件方案，如
Windows 2000 Advanced Server中的Network Load Balancing和Cisco的Local D
irector。当然，这些方案并不完美，都要损失一些可伸缩性。Application对象
也不是跨服务器的，如果你想在多服务器间共享和更新Application数据，你必须
使用一个后台数据库。但无论如何，只读Application数据在多服务器环境中还是
十分有用的。
绝大多数任务优先（mission-critical）的站点都想在至少两台Web服务器上发布
--如果没有比延长正常运行时间更重要的理由的话。因此，在设计阶段，你就要
实现“粘Session”，或是简单地避免Session和其他将用户状态保存在一个独立
Web服务器上的状态管理技术。
如果不使用Session，就将它们关闭；可以通过Internet Service Manager（参看
ISM文档）关闭你的应用的Session功能。如果决定使用Session，就要用一些方法
将他们对性能的影响减到最小。可以将不需要Session的内容（如帮助窗口等）移
到一个的关闭了Session的ASP应用中。如果某个单一页面不需要Session，可以将
下面的语句放在页面的顶部来禁止Session功能：
使用该语句还有一个原因是Session在帧中会产生一个有趣的问题。ASP保证任何
时候一个会话只有一个请求，这就导致如果浏览器同时请求多个页面，同一时刻
将只有一个ASP请求能够访问Session；这避免了访问Session对象时产生的多线程
问题；但很不幸，一个帧中的多个页面只能顺序的生成，一个接着一个，而不是
兵法。用户可能会为多个帧等待较长时间。所以如果帧中的某个页面没有使用Se
ssion.就关闭它。
