SharePoint and ASP.Net Session State - Why Not?

April 15, 2005 01:00 by keithkaragan
The prevailing wisdom in MS-centric web development over the past near-decade (since ASP) is that if your building scalable solutions, don't use session state. This wisdom prevails today even with the improvements in performance of session state management in ASP.Net, although I haven't seen any severe performance issues using session state in a few of the applications I've created in ASP.Net - and some of these site were large scale and had significant traffic (and were admittedly built on some powerful machines, with redundancy). So my position has definitely softened on this, part experiences with a particular application that had so much code in it that I was amazed it ran with any performance at all (I was tasked with adapting this app, and adding more functionality to it - but the initial code base was huge). In fact, when debugging this beast performance was horrible - but compiled in release mode, and running on production hardware it was amazingly fast - and used session state to hold quite a bit of data.
Move forward to SharePoint 2003,a nd some similarities come to light: Big sites on low-end (development) hardware run and debug really slowly; Performance is pretty good on high quality servers, and when not debugging; And there is a whole lot of stuff going on in every page that loads up. At some level I'm thinking - so how much 'more' overhead is managing a session going to add to this ... probably not a hell of a lot.
True, the SafeMode processing for unghosted pages will require every page to participate in session state management - but then again this is generally the case in any site using session state anyway (of course it doesn't need to be that way in an ASP.Net app - but it usually is). True, there are alternatives for saving user info in SharePoint - but what doors would a common preferences add to a SharePoint app if performance was not adversely impacted?
Since most of the opinions online seem to be in-line with Microsoft's best practices - the performance story on SharePoint and Session State is most likely a true one, however the language used on the sites I visited (including Microsoft's) are all so close I'm tending to think these are mostly academic analysis of the issue (and to be fair - there really isn't all that much out there on the topic either). This makes my wheels turn, and after thinking about this for a good part of the day while doing other other stuff I think that the warning to stay clear of this integration may be overstated. I do plan on trying this out, and seeing what applications for the integration exist that have value - otherwise this is a severe waste of time to think about.
Best Practices are a double edge sword, and a well known one at that. Sure, they help to streamline production and increase productivity - exactly what they are meant to do. Unfortunately they also tend to minimize creative approaches to problems, because the process of creativity is not a best practice - and is counter productive. I say this from the vantage point of never really having to deal with the impact of best practices being shoved down my throat since I generally work on projects that are leaning toward the innovative side of things, rather than the day-to-day management of those same systems after they launch - where best practices are a way of life (I'm sure there are legions of people who curse me everyday as they maintain the systems that I participated in creating ... but that goes with the territory).
Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Related posts

Comments are closed