我正在开发一个轻量级的在线商店。这个商店集成了各种来源。它可以作为不同场景的“插件”。即会计软件包的插件，用于在网上销售本地股票，并反映销售回报等。
我的困境是：我正在努力就如何最好地实施国家信息做出明确的决定。这个商店是基于模板的，所以我在初始着陆时从数据库加载所有模板细节。然后我将这些细节存储在会话变量中，并在商店正在做的时候使用它来设置元素的样式。
我担心负载......我很容易在工作进程中达到100MB。它似乎徘徊在100MB以下。但我担心可扩展性。我需要这个商店来处理数百个并发用户。
商店本身不会做任何数据库请求。所有内容都从Web服务/服务（WCF）中消耗并放入会话变量中。如果会话变量为空，则只会从Web Reference加载/重新加载会话变量。
我现在的主持人给我打了100MB。这会强制我的工作进程被回收，导致查看macstate提交错误并重置我的会话。我已经在我的本地IIS上工作，无论我做什么，都无法让它真正增长超过100MB。它似乎跳到了大约80MB，然后在那里因为内存被回收等而定居。
我肯定会手动回收所有我的WCF构想和变量，因为它们完成了它们的目的。所以我找不到任何内存泄漏。正如我所说，它并没有真正增长，只使用了x量的内存，然后真的在那里徘徊......略微向上或向下......
我应该考虑将我的会话存储在数据库而不是内存中吗？
或者我应该完全改变我的方法？你会关注什么意见？
答案 0 :(得分：1)
模板是否按用户级别加载？如果没有，那么应用程序状态似乎更适合它。如果是，那么会话状态可能是要走的路。
我会选择基于数据库的进程外会话状态管理解决方案，因为您的会话状态还将包含购物车内容和内容等内容。您不希望人们在会话中丢失所有内容，因为您的服务器在某些时候会崩溃。您希望确保在Web服务器崩溃并恢复后，购物车中的每个事务（待处理或已完成）和每个项目都已保存并可供检索。
答案 1 :(得分：0)
如果你必须在会话状态中存储这么多，并且你对进程内存有限，那么数据库似乎就是这样。只需确保您放入Session的所有内容都是可序列化的，因为这是必需的。更多细节见MSDN。数据库选项当然是SessionStateMode.SQLServer。
答案 2 :(得分：0)
如果每个用户的模板都相同，您也可以将它们存储在Application变量中（与会话相同，除了所有用户的一个变量）。
如果你怀疑某些变量消耗了大量内存，但是很少使用，你也可以考虑Cache。系统将删除未自动使用的对象，但您需要实现一些代码以“智能”从数据库加载。