在会话状态中存储数据的不同方式答案

【问题标题】：Different ways of storing data in session state在会话状态中存储数据的不同方式
【发布时间】：2008-12-24 04:27:14
【问题描述】：

有人要求我为 ASP .NET / MVC C# 3.5 Web 应用程序提出状态管理策略

我选择在状态服务器上存储会话 - 这将是一个单独的物理框。我担心存储到会话中时序列化/反序列化对象所花费的时间...

有没有人知道在执行此操作时获得最佳性能的技术？

还可以在将信息存储在会话帮助中之前对其进行压缩，或者这也会导致性能时间变慢。

编辑：我为状态服务器使用了一个单独的框，因为我们将有多个 Web 服务器。

【问题讨论】：

标签： asp.net session-state

【解决方案1】：

个人而言，这里最常见的元素是减少投入会话的信息量。

压缩可能会节省空间，但完成它需要更多的 CPU 时间，很可能会导致性能下降或至少没有净收益。除非你说的是非常大的物体。

【讨论】：

【解决方案2】：

Example 的 Zip Compression on Session、Application 和 Cache，在 StackOverflow 上使用。

【讨论】：

我在播客上听到 Jeff 谈论过这个。感谢您的链接 - 非常有用。

【解决方案3】：

确保在不使用会话状态的页面上禁用它。 “默认情况下，ASP.NET 会话状态管理器对每个请求中的会话数据存储执行两次访问——一次读取访问和一次写入访问，无论请求的页面是否使用会话状态。” --MSDN Magazine

【讨论】：

【解决方案4】：

请注意不要过早地优化您的解决方案。在实现会话压缩之类的东西之前，最好进行一系列基准测试以确定您的应用程序中是否需要这样做。

【讨论】：

【解决方案5】：

您确定要在会话存储中存储这么多数据吗？单个用户会话的典型使用是几百字节！

至于序列化和反序列化，那么小的尺寸可以忽略。

当然，您会期待更多的用户，但仍然如此。

如果您在会话中存储大量数据，那么 IMO，您做错了。

【讨论】：

【解决方案6】：

一些人指出每个用户的会话状态中的数据过多是问题的征兆，但他们并没有直接指出解决方案：保留一个用户 SQL 数据库并将所有用户信息存储在其中.然后会话状态通常只包含登录用户的 ID。任何其他状态都可能与用户的当前活动直接相关，这表明它可能更适合作为内存中的 cookie 或查询字符串变量进行携带。无论如何，这通常是更好的选择，这样当用户单击后退和前进按钮时，事情就会进入损坏状态。

【讨论】：