ASP .Net中的Sessions有什么问题

Question

我一直听说在会话中存储大型对象集合/任何内容是不好的做法。通常在谈话过程中，很快就会出现：'只需关闭会议'

那么会话的一般问题是什么？我使用它们相当一点，因为它们'真实'会话存储在一个强类型容器后面，我真的没有看到这个问题。

Answer 1

会话没有问题 - 你只需要注意它的局限性。说“只是关闭会议”就是把婴儿扔出洗澡水。

Answer 2

在会话中存储BIG对象和小对象之间存在巨大差异

会话将在服务器上保持活动状态，直到它过期，这意味着那些大对象会污染您的可用内存。如果您在加载服务器或运行许多应用程序池的服务器上执行此操作，则会导致问题。

您不需要cookie来进行会话，因为ASP cal还会在网址中对该信息进行编码。您还可以将会话存储配置为在进程外运行，甚至将信息存储在SQL Server中（减少服务器上的内存负载，并在服务器场中启用会话）

所以基本上：对象没问题 - 大对象不是

Answer 3

这是我的参与 - 会议并不差，但有时它们被过度使用。当Web应用程序依赖于大量会话时，它也可能更难理解它，因此当然您应该小心不要被带走。

但是，您可以随时使用它们，以便存储临时数据以便跨多个页面访问。在任何其他情况下都不应该使用它们。但这种情况是专门为会议设计的。

现在，如果您担心服务器上的内存消耗，这不一定是避免会话的理由。但是，避免使用InProc会话提供程序可能更有理由。事实上，我不是InProc会话的粉丝，因为在你的应用程序中进行了一定数量的重新编译后，它们会过早地过期。

我真正喜欢并且几乎总是使用的是SQL Server会话。它们会稍慢，但好处很多。即使重新启动服务器，它们也会持续存在，这使它们成为一个非常可靠的选择。当然，因为它们存储在SQL文件系统而不是内存中，所以它们不会对内存产生如此大的影响。

This article on MSDN讨论了各种会话提供程序，并解释了如何配置SQL来处理会话。如果您没有SQL，只需知道即使是免费的SQL Server Express 2008也可以配置为您的会话提供程序。

Answer 4

我原以为这在很大程度上取决于您网站的流量。如果您正在运行像amazon.com这样的东西，尝试将用户的购物车存储在会话中会占用大量IIS分配的内存，从而导致您的Web服务器崩溃。对于较小的网站，会话变量可以适度使用。

Answer 5

在Session中存储大对象是坏的，是的，但“大”是相对的。

基本上，在会话中存储对象会将其保留在内存中，直到会话到期为止，因此如果您的网站用户数很多，所有会话中都存储了大型对象，那么您很快就会杀死服务器。 / p>

话虽如此，可以提出一个观点，即如果你的内存中有5k +的对象并且有足够的用户来实际设置服务器，那么无论如何你都可能买得起更多的硬件。

群集中的框之间还存在服务器群集和会话完整性等主题。有些框架会处理这个，我不知道.NET是否会这样做。

Answer 6

有两件事需要注意：

1. 内存消耗：如果您在会话中存储大型数据对象并且您拥有许多用户，则可能会耗尽内存或至少触发许多应用程序的早期回收
2. 如果您有多个Web服务器（Web场），这只是一个问题：会话必须存储在SQL服务器或Windows服务的外部（不在进程中），以便可以从不同的计算机访问它。这有时会很慢。

Answer 7

1. 会话要求用户启用Cookie
2. 如果您在网络农场工作，则会遇到麻烦。

我猜这些原因与在会话中存储大型对象没有任何关系，只是在使用会话时。

Answer 8

我想到了两个主要问题...... 1）当您开始扩展网站时，跨服务器的会话持久性 2）在会话状态下存储UI对象的内存使用量激增

更严重的问题是在会话中存储对象的倾向。当您从页面上的页面存储像Label一样无害的东西时，您也会获得大量不需要的对象属性。你可能只是希望在你的会话中存储该标签的文本，但是随之而来的，你会得到对页面本身的引用......而且突然之间，你有大量的内存用来存储页面，它的视图状态，以及服务器内存中的许多不需要的属性。

请查看有关storing UI elements in session

的链接

Answer 9

您也可以查看this question。

Answer 10

这是旧线程。 但是我有一个会话问题的经验。我想分享。

有一个简单的流程。

1. 一个.aspx验证客户端，并从文件（为此客户端）中读取bill-html，然后将此html（约2MB）保存在会话变量中。

2. 此.aspx将自动重定向到下一个.aspx，下一个.aspx从会话中检索此html。然后将其显示给客户端。

在大多数情况下它可以正常工作。但是有些客户遇到了一个问题：他看到的账单不是他的账单，而是其他人。

我们使用了嗅探器工具来拦截网络软件包。 我们看到了一个奇怪的情况： 我们的IIS确实已将SessionID（例如：1111111）发送给客户端，但是当客户端重定向到下一页并尝试访问会话时。该客户端带来的SessionID（例如：11112222）是不同的。

我们认为该客户端的浏览器不接受SessionID。 最后，我们放弃了Session的使用，并解决了这个问题。