ASP.NET 和会话变量：我需要真实世界的意见
我正在开发一个轻量级的网上商店。这家店整合了各种资源。它本质上是作为不同场景的“插件”。即用于会计软件包的插件，用于在网络上销售本地库存并反映销售情况等。
我的困境是：我正在努力就如何最好地实施状态信息做出既定决定。这家商店是基于模板的，因此我在初次登陆时从数据库加载所有模板详细信息。然后，我将这些详细信息存储在会话变量中，并在商店执行操作时根据需要使用它来设置元素的样式。
我担心负载...我很容易在工作进程中达到 100MB。它似乎徘徊在 100MB 以下。但我担心可扩展性。我需要这家商店来处理数百个并发用户。
商店本身不做任何数据库请求。一切都从 Web 服务/服务 (WCF) 中使用并放入会话变量中。如果会话变量为空，则仅从 Web 参考加载/重新加载会话变量。
我当前的主机限制我的容量为 100MB。这迫使我的工作进程被回收，导致查看 macstate 归档错误并重置我的会话。我在本地 IIS 上进行测试，无论我做什么都无法让它真正增长超过 100MB。它似乎跳到大约 80MB，然后随着内存被回收等而稳定在那里。
当它们完成其目的时，我肯定会手动回收所有 WCF 连接和变量。所以我找不到内存泄漏。正如我所说，它并没有真正增长，只使用 x 量的内存，然后真正悬停在那里......稍微向上或向下......
我应该考虑将会话存储在数据库而不是内存中吗？
或者我应该完全改变我的方法？您对世界的看法是什么？
I am developing a light-weight online shop. This shop integrates with various sources. It absically serves as a "plugin" for different scenarios. I.e. Plugin for an accounting package to sell local stock on the web, and reflect sales back, etc.
My dilemma is this: I am battling to make a set decision on how to best implement the state information. This shop is template based, so I am loading all the template details from the DB on initial landing. I then store these details in session variable, and use it to set styles on elements as and when needed when the shop is doing its thing.
I am worried about load... I am easily reaching 100MB in in worker process. It seems to hover just under 100MB. But I am worried about scalability. I will need this shop to handle hundreds of concurrent users.
The shop itself does nto do any database requests. Everything is consumed from a web service/service (WCF) and put into session variables. And session variables only get loaded/re-loaded from the Web Reference if they are empty.
My current host caps me on 100MB. Which forces my worker process to be recycled, causing a view macstate filed error and resetting my session. I have benched on my local IIS and cant get it to really grow more than 100MB no matter what I do. It seems to jump to about 80MB and then settle there as memory gets recycled etc.
I am definately manually recycling all my WCF conenctions and variables as they are done srving their purpose. SO no memory leaks that I can find. As I said, it does not really grow, only uses x amount of memory, and then really hovers there.. slightly up or down...
Should I considder storing my session in a DB rather than memory?
Or should I change my approach completely? What would be you rela worl opinions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
模板是否在每个用户级别加载？如果没有，那么应用程序状态似乎更合适。如果是的话，那么会话状态可能是正确的选择。
我会选择进程外、基于数据库的会话状态管理解决方案，因为您的会话状态还将包含诸如购物车内容之类的内容。您不希望人们仅仅因为您的服务器在某个时刻崩溃而失去会话中的所有内容。您希望确保每笔交易（待处理或已完成）和购物车中的每件商品均已保存，并可在 Web 服务器崩溃并恢复后进行检索。
Is the template being loaded on a per-user level? If not, then Application State seems more appropriate for it. If it is, then yeah Session State is probably the way to go.
I would opt for an out-of-process, database-based Session State management solution, because your session state will also contain things like shopping cart contents and stuff. You don't want people to lose everything in their session just because your server craps out at some point. You want to make sure that every transaction (pending or finalized) and every item in the shopping cart is saved and available for retrieval after your web server crashes and is restored.
如果您必须在会话状态中存储这么多内容，并且进程内存有限，那么数据库似乎是最佳选择。只需确保您放入
Session中的所有内容都是可序列化的，因为这是必需的。更多详细信息请参见 MSDN。数据库选项当然是SessionStateMode.SQLServer。If you must store this much in session state, and you're limited on process memory, then it seems like the database would be the way to go. Just make sure that everything you are putting in
Sessionis serializable, since that will be required. More details are on MSDN. The database option is, of course,SessionStateMode.SQLServer.如果每个用户的模板都相同，您还可以将它们存储在
中应用程序变量（与会话相同，除了一个适用于所有用户的变量）。如果您怀疑某些变量消耗大量内存，但很少使用，您还可以考虑
缓存。系统会自动删除不使用的对象，但是您需要实现一些代码来“智能”从数据库加载对象。If the templates are the same for every user, you could also store them in
Applicationvariables, (the same as session except one variable for all users).If you suspect some variables to consume a lot of memory, but are sparsely use, you could also think about the
Cache. The system will remove the objects that are not used automatically, but you need to implement some code to "smart" load the from the database.