When Session Variables Go Bad - Cap'n. The Resources. They Canna Take It!
(Page 3 of 4 )
Forgetting about the threading issues, there are a number of less esoteric issues that impact the use of Session variables. The strain on server memory can get quite high, depending on the usage of your web site.
As we mentioned earlier, Session variables are implemented as a collection. Actually, as a collection of Variants. This means that for every session, you not only have the data being stored, but also the implementation of the Add, Remote, Item and Count methods, as well as the IEnum interface. Then, since it is a collection of variants, the collection also needs to implement the IEnumVariant interface. Finally, the values in the collection are tied together using a linked list. So if you add even a small piece of data to the session variables, the memory usage might seem way out of whack.
Now in the connectionless world of HTTP, there is no way for the application to know when a user is done with their session. So IIS implements a session timeout mechanism. By default, it is twenty minutes, but it can easily be configured by the web site administrator. This value does significantly impact the resource usage of the web server. Let's say that you get 1000 users an hour on your site. That means that, on average, you will have 330 sessions active (okay, 333, but the math is easier if there are zeros). Say each session takes up 4KB of space. That means that 1.3 MB would be constantly allocated on the server. Not a problem, you say? Fine. So long as you keep ratcheting up the server memory as your site becomes more popular.
Down on the Web Farm Our final issue with Session variables arises when your application get scaled out across a number of servers. Typically, when you have multiple servers processing the requests for a single site (a web farm), there is some load balancing hardware or software that determines the lucky server that gets the next request. The most common algorithm used by the load balancer is a simple round robin. You think that you had problems with thread affinity! All of the Session variables are sitting on the server which handled the initial assignment. So if it should happen that the next page request is processed by a different server, all of the session information is lost. Now to be fair, there is software available that will 'pin' all of the page requests from a single session to one server. In fact Microsoft's Load Balancing Service will do that for you. However you are reducing the overall performance of the application. You could easily get the situation where one server is processing four or five sessions while there are other servers sitting idle.
Next: Conclusion >>
More ASP Articles
More By Bruce Johnson
