Question: I have inherited a project from a developer who was rather fond of session variables. He has used them to store all sorts of global stuff - datatables, datasets, locations of files, connection strings etc. I am a little worried that this may not be very scalable and we do have the possibility of a lot more users in the immediate future.

Am I right to be concerned, and if so why?
Is there an easy way to see how much memory this is all using on the live server at the moment?
What would be the best approach for re-factoring this to use a better solution?

Answer: 
Yes, I would say that you do have some cause for concern. Overuse of session can cause a lot of performance issues. Ideally, session should only be used for information that is specific to the user. Obviously there are exceptions to this rule, but keep that in mind when you're refactoring. 

As for the refactoring itself, I would look into caching any large objects that are *not* user-specific, and removing anything that doesn't need to be in session. Don't be afraid to make a few trips to the database to retrieve information when you need it. Go with the option that puts the least *overall* strain on the server. The trick is keeping it balanced and distributing the weight as evenly as possible across the various layers of the application.
You are right in feeling concerned about this. 

Connection strings should be stored in Web.config and always read from there. The `Web.config` file is cached, so storing things in there and then on `Session` is redundant and unnecessary. The same can be said for locations of files: you can probably create key,value pairs in the `appSettings` section of your web.config to store this information.

As far as storing datasets, datatables, etc; I would only store this information on `Session` if getting them from the database is really expensive and provided the data is not too big. A lot of people tend to do this kind of thing w/o realizing that their queries are very fast and that database connections are pooled. 

If getting the data from the database does take long, the first thing I would try to remedy would be the speed of my queries. Am I missing indexes? What does the execution plan of my queries show? Am I doing table scans, etc., etc.

One scenario where I currently store information on `Session` (or `Cache`) is when I do have to call an external web service that takes more than 2 secs on average to retrieve what I need. Once I get this data I don't need to getting again on every page hit, so I cache it.

Obviously an application that stores pretty much everything it can on `Session` is going to have scalability issues because memory is a limited resource.