Session Varibles are so easy to use

We are primarily a .Net shop so most of our technical post will be from the .Net perspective, with emphasis on C#. When you start an application most developers, myself included are tempted to use the Session variables that are oh so easy to use.  You simply store your information in the Session["object"] = object,  to retrieve your information you just remember to properly cast your object and call the Session["object"]. It is one of the easiest functions in .Net programming.

Nothing in development comes free. Open Source is free but usually cost you in other ways.  When you first create your application the default for storing your Session is in-proc which means the sessions are stored on the machine, which is no problem.  However what happens when you scale? The session does not survive from one web server to another, you must create another method to store your Session variables. The most common are Sql and state server. I am going to cover SQL, the most common. 

I honestly thought this was the best solution, then I got to examining exactly how the Sessions work.  Let's say you have a Customer object serialized to store in the SQL State Server. You store it using the simple syntax

Session["customerobj"] = customerObj;

This is what happened probably happened.
-You built the object from a database
-You stored the Session, which then stored the object in the SqlState database
-When you recalled the Session["customerobj"] then you hit the SqlState database again

So you are really hitting the database multiple times for a single Session object.  Which is why some experts say Session objects decrease performance by 15%.

The next problem, the Session object takes up RAM on the server, one of the most expensive components of a cloud solution.

So what is the solution? That will be covered in another post. I just wanted to give my perspective on a simple but costly item of .Net development.

Jeffrey