我继承了对经典 ASP 应用程序的修复，我们希望在该应用程序中存储一些用户会话特定的数据以在页面加载/他们的会话中持续存在，并且需要一些复习。
在过去，我只是简单地使用了 Session 变量——即。Session("SomeVar") = SomeVal.
在生产框中的 IIS 上，我注意到 ASP/Session Properties/Enable Session State = false。将此设置为 True 使我能够成功开始使用会话变量。
我不想在服务器上消耗比必要更多的资源。过去，我相信我误以为经典 ASP 中的会话变量存储在客户端。现在重新审视这个 - 数据保留在服务器端。
我保存的字符串是一个 GUID，用于大约 3000 个连接的客户端。
如果我实现这一点，我会看到什么样的服务器影响，并且使用客户端 cookie 会是更好的选择吗？
让我们稍微分析一下，GUID 需要大约 40 个字符作为字符串，因此在 Unicode 中是 80 个字节，我们称之为 100 个字节。100 * 3000 = 300KB。服务器可以为此腾出300K吗？如果答案是否定的，我认为服务器已经有麻烦了。
但是，启用会话状态还有其他影响。当会话启用时，ASP 将它自己的 cookie 添加到客户端，它在大小上可能等同于您将 GUID 存储为 cookie 而不是会话中所需的那个。值得注意的是，存储在 cookie 中的会话 ID 使用了一种算法，有人说这种算法更可预测（我自己没有任何证据）。因此，如果您使用 GUID 作为某种形式的授权，那么直接将 GUID 存储为 cookie 可能会更好。
启用会话状态时会发生进一步的重大变化。来自客户端的 ASP 请求必须串行处理，服务器不会并行处理来自同一客户端的多个请求。这是因为 Session 对象是单线程的，并且由于来自客户端的每个请求都需要访问它，因此无法同时处理请求。
最后一点可能会对客户端看到的现有行为和性能产生重大影响，尤其是在使用 AJAX 技术、多个 IFrame 或其他导致同时向服务器发送 ASP 请求的技术时。
因此，对于您的要求，我的选择是将 GUID 存储在 cookie 中并关闭会话状态。
多个服务器/服务器场？如果是这样，如果您的负载均衡器未设置为“粘性”并且每次都将您发送到同一台服务器，您可能会在使用 Session 时遇到麻烦。能不能把我调试得这么小心翼翼。