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

Question

我从开发人员那里继承了一个非常喜欢会话变量的项目。他用它们来存储各种全局的东西 - 数据表，数据集，文件位置，连接字符串等。我有点担心这可能不是很可扩展，我们确实有可能会有更多的用户立即将来

我是否有理由担心，如果是这样，为什么？ 有没有一种简单的方法可以看到目前在实时服务器上使用了多少内存？ 什么是重新分解这个以使用更好的解决方案的最佳方法？

Answer 1

这可能是由于设计不佳，是的，如果您计划增加流量或缩放网站，您应该担心。
连接字符串应存储在web.config中。看起来你必须重新设计数据层以及页面如何相互传递数据以避免在Session中存储数据表和数据集。例如，不是将整个数据集存储在Session中，存储或通过url传递，而是可以用来重新查询数据库的小东西（如ID）。

Answer 2

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

至于重构本身，我会考虑缓存不特定于用户的任何大对象，并删除任何不需要在会话中的对象。不要害怕在数据库中进行一些访问以在需要时检索信息。使用将整体应变最小的选项放在服务器上。诀窍是保持平衡并在应用的各个层上尽可能均匀地分配重量。

Answer 3

会话总是会影响可扩展性。但是，一旦使用会话，会话中的更多数据的影响就不那么糟了。

但是，它必须存储在某个地方，必须从某个地方检索，所以它会产生影响。如果你不得不搬到一个网络农场来处理非常成功的话，那将会非常痛苦，因为以可扩展的方式做得更好。我首先要采取真正意义上的全球性（在所有会话之间共享）并将其转移到真正全球可访问的位置。

然后依赖于先前请求的任何事情，我都会被该请求发送。

同时执行这两项操作会大大减少它们的使用量（可能足以关闭会话并获得大量的可扩展性提升）。

Answer 4

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

Answer 5

你对此感到担忧是正确的。

连接字符串应存储在Web.config中，并始终从那里读取。 Web.config文件被缓存，因此将内容存储在那里，然后存储在Session上是多余且不必要的。对于文件的位置也可以这样说：您可以在web.config的appSettings部分创建键值对，以存储此信息。

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

如果从数据库获取数据确实需要很长时间，我首先要尝试解决的问题是查询速度。我错过了索引吗？我的查询的执行计划显示了什么？我在做表扫描等等。

我目前在Session（或Cache）上存储信息的一种情况是，当我必须调用平均需要2秒以上的外部Web服务来检索我需要的内容时。一旦我得到这些数据，我就不需要在每次点击时再次获取，所以我将其缓存。

显然，在Session上存储几乎所有内容的应用程序将会出现可伸缩性问题，因为内存是一种有限的资源。

Answer 6

总的来说，你应该关注这一点。

Session是内存中的“每用户”类型的存储。查看ASP.NET辅助进程的内存使用情况可以让您了解内存使用情况，但如果您想深入了解其中的内容，则可能需要使用第三方工具。此外，会话变得非常有趣“当你开始负载平衡等。

ConnectionStrings和非“每用户”的其他信息实际上不应在“每用户”存储位置处理。

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

Answer 7

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

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

问题是存储在sql server中的类必须是可序列化的，你可以使用json.net来做到这一点。