I am watching the ASP.NET learn videos on asp.net/learn. In this tutorial, they are building a quiz engine. At one point, the narrator explains that we are going to use the Session object to maintain the state between each page (each page contains a question and four answers). He says that “since this is a low traffic website” it is okay to use Session and that he doesn’t have the time to implement a more sophisticated method.
I am just wondering what alternate method(s) is he hinting at? And why is session a bad choice for a high traffic website?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
Storing data in a database, or in cookies or some other method that is not directly tying up web server memory.
In addition to load, session also raises issues with the ability to use farms since you would either need to synchronize the session across the farm, or make sessions sticky, which can impact scalability.
Method 2
For alternatives you can read the article Nine Options for Managing Persistent User State in Your ASP.NET Application.
In the articles the author explains the pros and cons of each method.
From the summary:
ASP.NET provides many different ways
to persist data between user requests.
You can use the Application object,
cookies, hidden fields, the Session or
Cache objects, and lots of other
methods. Deciding when to use each of
these can sometimes be difficult. This
article will introduce the
aforementioned techniques and present
some guidelines on when to use them.
Although many of these techniques
existed in classic ASP, best practices
for when to use them have changed with
the introduction of the .NET
Framework. To persist data in ASP.NET,
you’ll have to adjust what you learned
previously about handling state in
ASP.
Method 3
Session data is stored in the RAM of the server, if you have a high traffic site that is going to get full real quick and the last thing you want is that data being swapped to disk.
As gaijin42 says, cookies or a DB are the alternative.
Method 4
Session as a state storage method is rough in high traffic systems for several reasons.
First, the default Session storage method is in-process, meaning that if you have a load-balanced web farm, you’ll constantly ‘lose’ Session information as a user gets pages served from different servers.
The in-proc Session server also dies when an app pool is recycled, which happens more often on higher traffic servers.
The scalability options for Session data are
- Use the freely available ASP.NET
Session Server and point all your
applications at it - Use SQL Server to store Session data.
Due to the nature of Session data in general, neither of these is a very good option for a very high traffic site (unless you have unlimited money to throw at the hardware).
Method 5
For high traffic websites you might be looking at Memcached. It is a caching mecanism that is stored on the RAM of a remote computer. Just recently a win32 port has been made of the library (was only possible with linux before).
Method 6
I’m not going to repeat what was already mentioned here, but another alternative is using the Application hash. It should be used sparingly, since it will consume memory on your web server as Adam has already mentioned, but it does provide a good way to cache things that are common across ALL your users.
This keeps you from having to go back to your database to retrieve information that most likely was already asked for by someone else.
Another alternative similar to Application is Cache which has more flexibility in terms of when it gets released, duration, etc.
Here’s some links in case you’re interested:
ASP NET Caching Application State
Method 7
We use a database for anything high traffic or that will result in large session state. Instead we store a pointer in the real sessionstate that points to our database record. Then the only overhead we have is the bandwidth between the web server and database server which will be much less than between any given user and the web server.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0