用于存储所有全局数据的Asp.net会话变量

是的，我想说你确实有一些担心的理由。过度使用会话会导致很多性能问题。理想情况下，会话应该仅用于特定于用户的信息。显然，这条规则也有例外，但在重构时请记住这一点。

至于重构本身，我会考虑缓存任何不是特定于用户的大对象，并删除任何不需要在会话中的对象。当您需要检索信息时，不要害怕多次访问数据库。选择给服务器带来最小总体压力的选项。诀窍是保持它的平衡，并在应用程序的各个层之间尽可能均匀地分配权重。

这可能是由于糟糕的设计，是的，如果你计划获得更大的流量或扩展网站，你应该关注。
连接字符串应该存储在web.config中。似乎您必须重新设计数据层以及页面如何相互传递数据以避免在会话中存储数据表和数据集。例如，不是将整个数据集存储在Session中，而是通过url存储或传递一些可以用于重新查询数据库的小数据(如ID)。

会话总是影响可伸缩性。然而，一旦会话被使用，会话中多一点数据的影响并不是那么糟糕。

但是，它必须存储在某个地方，必须从某个地方检索，所以它会产生影响。如果你为了获得成功而不得不转向网络农场，这将会对你造成伤害，因为这很难以可扩展的方式做好。我会从真正意义上的全局(在所有会话之间共享)开始，并将其移动到真正的全局可访问位置。

那么任何依赖于前一个请求的东西，我都将被该请求发送。

做这两件事会极大地减少它们的使用量(也许足以关闭会话并获得巨大的可伸缩性提升)。

根据IIS版本，使用Session来存储状态可能会对可伸缩性产生影响。IIS的最新版本更好。然而，我遇到的主要问题是会话过期，然后你的数据丢失;你可以提供你自己的Session_OnEnd处理程序，它可以重新生成你的会话。

总的来说，是的，你应该关注这个

Session是内存中"每用户"类型的存储。查看ASP的内存使用情况。. NET Worker Process会给你一个内存使用的概念，但如果你想更深入地挖掘它，你可能需要使用第三方工具。此外，当你开始负载平衡等时，会话变得非常"有趣"。

ConnectionStrings和其他不是"每个用户"的信息真的不应该在"每个用户"的存储位置中处理。

至于为此创建解决方案，很多将取决于数据本身，因为您可能需要找到多个其他机会/位置来获取/存储信息。

你对这件事的担心是对的。

连接字符串应该存储在Web中。配置并始终从那里读取。Web.config文件是缓存的，所以在那里存储东西，然后在Session是多余的和不必要的。对于文件的位置也可以这样说:您可能可以在web的appSettings部分创建键、值对。配置以存储此信息。

至于存储数据集、数据表等;如果从数据库获取这些信息非常昂贵，并且数据不是太大，我只会将这些信息存储在Session上。很多人倾向于做这种事情，但没有意识到他们的查询非常快，数据库连接是池化的。

如果从数据库中获取数据确实需要很长时间，那么我要尝试补救的第一件事就是我的查询速度。是不是漏掉了索引?查询的执行计划显示了什么?我正在做表扫描，等等，等等。

我目前在Session(或Cache)上存储信息的一个场景是，当我必须调用平均需要2秒以上的外部web服务来检索我需要的内容时。一旦我得到了这些数据，我就不需要在每次页面点击时再次获取，所以我缓存了它。

显然，一个应用程序，它可以在Session上存储几乎所有的东西，将有可伸缩性问题，因为内存是一个有限的资源。

如果内存是问题，为什么不将会话模式更改为SQL server，这样你就可以在SQL server中存储会话数据，这需要很少的代码更改。

如何在SQL server中存储会话数据:http://msdn.microsoft.com/en-us/library/ms178586.aspx

问题是存储在SQL server中的类必须是可序列化的，您可以使用json.net来实现这一点。