在我的.NET Web应用程序中，我将基本用户信息保存在用户会话对象中。我通常还会在会议上保持一个导演班;这基本上只是关于它在屏幕上工作的任何信息（如客户ID）。
我试图避免添加大量会话。我还想确保在任何给定的时间内只有必要的会话在记忆中。
这意味着我需要一种有效的方法来管理会话变量。有什么建议？
答案 0 :(得分：1)
两件事：
1 - 您不应该在会话中存储太多关于管理内存的问题。即，不存储在会话对象，存储指向的东西，例如，而不是用户的一个实例，只存储用户名。如果需要，可以添加信息检索的缓存，但这应该在与会话分开的缓存层中。
2 - 使用数据库会话，所以不存在有关服务器内存的关注，让您可以根据需要轻松添加更多的Web服务器（注意，StateServer给你这种能力以及）。此外，这使您可以回收应用程序池，而无需用户丢失会话。这是我这样做的主要原因 - 它让我可以动态部署。
治疗会话得这么细的原因是，它们流连用户最近的请求后，典型地为10至20分钟。因此，如果要在会话中存储大对象，来自许多不同会话的请求可能会占用大量服务器内存。这样做更疯狂的事情，比如在会话中存储数据库连接，可能会导致您在使用所有可用的数据库连接的，只是因为很多都挂在内存中等待会话过期。
理想情况下，不需要“管理”会话。
答案 1 :(得分：0)
我认为你在ASP.NET中误解了会话。您没有明确地管理它们（尽管您可能，您很少想要），它们是由ASP.NET和IIS隐式创建和销毁的。每个用户都有一个会话。
现在存储在用户会话中的任何内容都存储在服务器的内存中，因此如果您经常在每个用户会话中放置大对象，这将导致内存快速增长，从而导致性能和可伸缩性问题。
您需要在会话中存储的唯一数据是您希望在您希望受到保护的不同页面请求中可用的临时数据，以便客户端无法在cookie或类似构造中使用这些数据。
然而，阅读你正在做的事情很可能不需要。由于您正在使用特定页面和“导演”功能，因此这很可能适合作为中间数据存储放置在视图状态的页面上。
答案 2 :(得分：0)
没有正确的答案。这取决于并发用户的数量，内存的大小。 如果在proc中有会话变量，那么保持会话比在数据库上更快。 我通常会尝试在特定任务中保留用户可能需要的东西，或者像你说的那样，保留当前用户的信息。
答案 3 :(得分：0)
我通常做的只是在Session中保留一个对象的id，并将数据保存在数据库前面的缓存层中。这样，您可以保持会话相当小，但如果项目位于缓存中，仍可以有效地检索大多数数据。这通常对我有用。
答案 4 :(得分：0)
我的建议是：
HTH。
答案 5 :(得分：-4)
我的建议：不要使用会话变量。将所有内容存储在数据库中。