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