This one is also a simpler one, but it is something that might only really be necessary, just before you have to go to a load balanced server farm, in an attempt to avoid having to go to a more complex web farm (which completely slows down session state on both platforms when you have to send session state through serialization methods)
You won't see any gains on this one on little used web applications, though overall, its usually much easier to maintain, and clean up session state if you do these techniques.
Often you will see situations where web applications will use a mix of many individual session state variables, and cookies to manage session state. Both of which have pro's and cons, so picking between them is really dependent on what the need is.
Session state variables
Pros: Fast, best for HPC (high performance coding situations)
Cons: Severs need more real memory to support heavy usage
Pros: Persistence past a session, for example, the remember login of this forum.
Cons: Uses more network traffic and bandwidth during heavy usage
So basic the first thing is to pick which Con it is that best fits an environment, and not use the other method at all, unless absolutely necessary. Keeping an application consistent in how it persists data, is a boon more to maintaining it faster later on, then in it operational speeds however.
I haven't done much with optimizing cookies, so i won't touch that, and leave that for those more knowledgeable.
However if you chose the Session state variables, then there is more that can be done as follows.
Often when dealing with a page that caches data in session variables, you will sometimes see the case where one page needs many different variables, sometimes upwards of twenty (I'll use this number going forwards though that is extreme).
Instead of making 20 method calls for each variable as it is needed, it is better to wrap all the variables a specific web application page needs, into a predefined data only Object (no getters or setters) that is flagged for either private or internal. And then make one single to the session state manager for that Object.
In the case of asp.net the following
Can better be done with a defined object containing the variables, and the seting or getting that object from the session state manager just one time.String var1 = session("var1");
String var2 = session("var2");
String var20 = session("var20");
Then after that just reference the variables in code using the PageVars.Var1 through var20 context as needed.internal MyPageState
MyPageState PageVars = session("thispagestate");
Besides good for HPC situation this can also lead to trimmer code to maintain, a bonus, and likewise when you need to clean up (destroy) a pages session states, it also become a one line of code operation. Additionally, the GC will operate slightly more efficiently on the the variables in one Object, then it would on 20 individual objects when they are not being referenced anymore. This also helps in preventing accidental session state variable garbage collection, when one variable hasn't been referenced in a while in code. Granted that is a rare issue I've only seen happen once in the last five years, that was a bear to debug though.
If you go with session state objects, be aware that if you wind up going to a server farm context anyway down the road (out of process session state), that you will have to add code to re-set the session state object, on every exit path of the web page. In this case, this sort of optimization could cost you more in performance then it saves. This is really only good for HPC when you are dealing with keeping things within the In Process session state context.
And don't expect to see a performance gain on this one on a page by page basis, this will really only bear fruit during heavy site load situations.