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.
if memory is the issue, why not change session mode to sql server so you can store session data in sql server which requires little code changes.

how to store session data in sql server:
<http://msdn.microsoft.com/en-us/library/ms178586.aspx>

the catch is that the classes stored in sql server must be serializable and you can use json.net to do just that.