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: 
It was probably due to poor design, and yes you should be concerned if you plan on getting heavier traffic or scaling the site.  

Connection strings should be stored in `web.config`. Seems like you would have to do some redesigning of the data-layer and how the pages pass data to each other to steer away from storing datatables and datasets in Session. For example, instead of storing a whole dataset in Session, store, or pass by url, something small (like an ID) that can be used to re-query the database.
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.