Classic ASP Session.Variables 成本高吗？答案

【问题标题】：Is Classic ASP Session.Variables costly?Classic ASP Session.Variables 成本高吗？
【发布时间】：2019-01-07 20:00:43
【问题描述】：

我已经阅读了很多关于 Classic Asp 中会话变量的文章。

我已经知道访问 Request.Servervariables 的成本很高，因为每次请求特定项目时，都必须通过 Asp 脚本从 IIS 获取整个集合。

我傻傻地想知道会话变量是否同样适用......？收集我在脚本启动时使用的几个 session.variables 是否是一个好主意，一次性全部？

以下文章建议（我也相信）Session.Contents 不会像 Request.ServerVariables 那样效率低下？因为 IIS 一次性提供了 Sesison：这是真的吗？ http://www.4guysfromrolla.com/webtech/092298-3.shtml

注意：我对会话变量的使用非常少，但我正在寻找每一点优化:)

【问题讨论】：

您只在服务器上使用Request.ServerVariables，不知道您所说的“从服务器获取”是什么意思？不管我从来没有遇到过Request.ServerVariables 或Session 变量的性能问题，事实上Session 变量是短暂的，除非您尝试存储复杂的对象，否则您永远不会遇到性能问题。但这都是使这个问题不适合Stack Overflow的意见。
这是一个很难回答的问题。这取决于使用情况。经典 ASP 中的会话由服务器上的 IIS 管理。作为一个比喻，将其视为每个用户私有的 csv 文件。如果您有数百万用户但会话数据很少，那么负担有一个配置文件，如果您有十个用户拥有一百万个大型会话变量，那么它还有另一个配置文件。会话数据将像任何其他服务器内存资源一样通过 IIS 进行管理，因此容易受到交换、磁盘等待等的影响。我的建议是着手使用 IIS 会话，然后在发现性能问题时制定另一种策略。
再补充一点，如果您打算扩展以使用简单的负载平衡或服务器场，那么使用 IIS 会话是有问题的。您可以在网络上的其他地方研究该问题和解决方案。对于 SO 来说，这不是一个好问题。
好的，我非常了解您认为我的问题不适合 StackOverflow。当有人判断问题而不是简单地提供最初想要的东西时，我总是很感激：anwser。所以感谢你对 ASP 会话的一般知识——我已经知道了（但你不应该被告知是这种情况）——我将来会避免问由外部链接说明的精确问题，用非- 规避公式。相反，我将尝试执行与 SO 的指南完全相反的建议。我们将看看它会导致什么。

标签： iis asp-classic session-variables iis-8

【解决方案1】：

完全正确。

简短的回答是，如果您需要一次会话变量（或应用程序，这是相同的），您可以直接使用它：

<%=session("userLastName")%>, <%=session("userFirstName")%>

如果您需要多次使用会话变量，请在本地进行复制（本例中为数组）：

<%
localAryCopy = session("myArray")
for each tmp in localAryCopy
    response.write tmp
next
%>

上周，有人问我为什么他的 asp 经典应用程序将 TTFB（到第一个字节的时间）设置为 3 秒。他多次使用 3 个会话变量（每个嵌入 3 个，总共大约 100 个循环）。我刚刚制作了本地副本，TTFB 下降到大约 50 毫秒。

【讨论】：

巨大的进步！我将进行一些测试以确保哪种解决方案对我来说更好，但是感谢您提供的明确证明的示例，以及您简洁的答案，这将引导我深入挖掘这个“会话事物”:-)