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?
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.