Why is it a bad idea to use Session to store state in high traffic websites?

Question

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?

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

Answer 2

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.

Answer 3

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

Answer 4

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

Answer 5

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

1. Use the freely available ASP.NET Session Server and point all your applications at it
2. 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).

Answer 6

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.

Answer 7

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.