Memory management in classic ASP Pages

Classic ASP has a wonderful feature of disposing of a session when a session is stateless. If the pages a visitor to a website browses to do not alter the session state or request the session ID, then the ASP engine considers this to be a stateless session and reclaims all the resources a session may hold at the end of each request.
 
Considering each session has some memory overhead, in a busy website the act of allocating a session and keeping the memory for every visitor will have some ramifications. If you get 1000 unique visitors to your website per minute, with the default value of 20 minutes per session, you will be keeping on average 20000 sessions on your server at any given time. If for each session you keep a lot of data... Well you can do the math.

In most cases, not all visitors to a site need to have a session associated with them. In a lot of scenarios when I visit a website, I don't need it to remember me while I am browsing the site. If in your code you have avoided any session specific behavior, such as setting a session variable or retrieving the session ID, ASP engine will play nice and destroy the session it created for the request at the end of the request for you.

This issue arose in one of our stress tests where we observed a small increase in memory consumption on some of the pages. On these pages, we were setting the Locale ID for the session using <%Session.LCID = some_value%>. I was puzzled to see that removing this directive from the page put an end to the increase although there were more script code on the page, which were seemingly unaffected by what I thought at the time to be a memory leak. It turns out all we were doing was altering the ASP session state, which in turn caused the ASP engine to keep the session alive in contrast to other pages which did not have session altering code.

But should we not use Sessions at all? In some cases you can't avoid them. But in this example we had some options. One of them was using Response.LCID instead of Session.LCID to get the same behavior. Another theory which needs to be confirmed is changing the setting from the metabase, which I suspect will change the default session state so you don’t have to change it in the code. And if no other page modifies it, stateless sessions will be disposed immediately while enjoying the desired LocaleID.

One final word is on Session.Timeout. If as a responsible system administrator you set the Session.Timeout to a value other than the default 20 minutes thinking maybe you will only use 5 minute sessions to conserve memory, you may have inadvertently increased the session timeout for stateless sessions that would otherwise be reclaimed immediately.

It is always a good idea to test any new code before stripping your code of all session related code. Remember: Your mileage may vary!