ASP.NET and SessionState have been available for a long time. In April 2010 we are about to see ASP.NET 4.
For those of us who were with ASP.NET from the beginning, I remember hearing a lot more about proven practices regarding the use of sessionstate, especially the use and concerns of using in-process sessionstate that used the server's memory. For performance you can't really beat the use of local server memory to store session data. However there were always some proven practices regarding that strategy:
- Keep the data small.
- Keep session timeouts short to eliminate data associated with abandoned sessions.
- In-process sessionstate may have serious implications where scalability is critical due to limited memory resources and non-use in a web server farm.
- etc..
Problem is I never hear this preaching anymore and I wonder if such proven practices are making its way to the new ASP.NET web developers who come on the scene.
Case in point. I ran across a new web application that suffered from improper use of in-memory sessionstate. The website suffered from those very proven practices I mentioned above: 1) The amount of data being stored in session was ridiculously big, 2) Session timeouts were drastically increased for unknown reasons, and 3) The web application in question needed to be scalable as it would eventually be part of a server farm.
In the interim, I applied a temporary bandaid to use SqlServer for out-of-process sessionstate management while the true nature of the problem could be determined. Not a big deal in the end, but it worries me that maybe new developers aren't getting enough of the basics, and instead, are pummeled with all the new technology in the community. Heck, did I say new developers? I could use more about the basics as well as the basics seem to always be changing.
As an FYI, while implementing SQL Server SessionState Management, I ran across an interesting change in ASP.NET 4 that introduces compression when using out-of-process sessionstate management. One can have ASP.NET 4 compress the data to be stored by setting a quick configuration setting- compressionEnabled = true:
Obviously compressing and deflating the data is gonna tax your server's CPU and you need to keep this in mind, but in those instances where you are handling large amounts of data in sessionstate, compressing the data can help performance across the wire. Still, you might want to ask yourself exactly why you are storing so much data in sessionstate and what other proven practices you may be ignoring in your use of sessionstate.
Hope this helps,
David Hayden