In ASP.NET, sessions enable us to store and retrieve values for a user as the user navigates ASP.NET pages in a web application. However, using too much sessions is discouraged. Why? What are the disadvantages of using too many sessions?
Thanks for those who will answer.
Memory and/or performance
If you store session state in-process (the default), all of your session data are stored in the app pool's local memory. If you have thousands of users you can see why this may be a problem. The problem gets worse when developers don't remove session variables after they're no longer needed (this is very common due to the fact that it's very hard to control the order in which web pages are accessed) and/or when users do not explicitly logout (e.g. by closing the browser window), which leaves all this memory still allocated but no longer used.
If you store session state out of process (e.g. in SQL Server or a separate state server), all of the session variables end up crossing the wire. As you add more variables, more and more data have to get pulled over. This can end up degrading performance.
Concurrency
If a web application uses session state, the data in which the session state is accessed has to be protected from race conditions and other multithreading concerns. As a result, ASP.NET automatically serializes any requests that use session. If you send two requests at the same time, ASP won't even start on the second request until the first one is finished. This can cause unexpected and poor performance on applications that use a lot of AJAX or other logic that is supposed to be asynchronous.
Infrastructure
If you're using local memory for session state, and your web app is load balanced, the load balancer must enforce session stickiness, either with IP address or a cookie. This constrains the load balancer in the way it can handle requests-- all requests for a certain session always hit the same server-- which reduces overall performance and eliminates redundancy.
Loss of data
If the app pool recycles, all sessions running on that app pool lose session state, often requiring users to log out and start over.
Poor code design
Session variables are essentially global variables. Overuse of global variables tends to lead to sloppy code structure. Variables should always be scoped as tightly as possible.
Basically, it consumes server memory. As generally sessions are stored in process, this solution doesn't scale well, as can't be shared between two or more state servers.
We have an MVC web app that uses FormsAuthentication and also stores a couple of variables in Session variables. We've encountered a few situations lately where the session variables are lost, but the user is still logged in. A quick Google lead me to a few SO articles mentioning that In Proc Session State is regularly lost and that if we require it to persist, we should consider moving to a non In Proc solution.
Coming from a classic ASP background, where we relied on Session state for the lifetime of the session, it seems a bit baffling that I now can't rely on it at all. Surely In Proc Session State is of no value to anyone if it can be lost at the drop of a hat? Am I missing something?
I realise that storing it in an SQL server has it's benefits, but for small webapps with little traffic, In Proc is an ideal solution, could it be relied upon.
ASP.NET session state is able to run in a separate process from the ASP.NET host process. If session state is in a separate process, the ASP.NET process can come and go while the session state process remains available. Of course, you can still use session state in process similar to classic ASP, too.
You don’t have to use SQL server to store session data in out of process, you can use out of process state server which can be in memory on the same server as the web server.
You can read more about how to configure out of process session state under http://msdn.microsoft.com/en-us/library/ms972429.aspx
As far as i know in-proc sessions state is lost after recompiling application and recycling application pool. App pool could be recycled if there is not enough memory or it's have regular restart time interval.
Are there any pre-conditions before storing any objects in session state.
I mean when will I not be able to insert an object in session state.
This was an interview question that was asked to me.
What could be the possible reason for not being able to store an object in session state?
Here are some that should be considered:
If it has more session data, then more memory is consumed on the web server, and that can affect performance.
It won't work in web garden mode, because in that mode multiple aspnet_wp.exe will be running on the same machine.
And if the appdomain or worker process (aspnet_wp.exe) restart/recycles very often then its not a good idea to use it
and it is gathered from here ... hope it answer your query ...
There are places in the asp.net page request life-cycle that you do not have access to the session state yet due to the lack of a valid user session such as Application_Authorize where we do not have an authenticated user yet, so Session will be null. The actual implementation of the Session store shouldn't really be a concern, neither should how the data is serialized.
On the website I am developing, I have a number of "user preferences" that I keep stored for my returning, registered users (for example, the number of product summaries per page to display). I am curious if there is any performance benefit to storing/retrieving this data in an ASP.Net SQLServer Session State versus retrieving it as-needed directly from my database. Many thanks in advance!
Its always better to store Data in Session State (performance point of view), as long as the data isn't too Huge. This way, you Production Data Database (where you persist your UserData) Hits would reduced. Just make sure that User Wouln't change his preferences which are cached in session.
Only potential problem with session is that Session is maintained per User. so, if there are too many users on your website, session state grows but since you are using SQL Server as you Session Store, you are good on that. Had you been using InProc SessionMode, your Session would have been in memory (a critical resource on production servers!)
You are taking the hit going to sql server anyways. So you shouldn't have a noticeable performance impact and also if using sql server for session state - you don't have to worry much about the implementation details - hence could be a 'bit' easier to use. But no - there is no main benefit. one could argue it depends on how you store/lookup your information but for most apps the difference here is absolutely negligible - it's up to you how you want to implement. Now if you ever move away from sql server session state then you have another set of issues to be concerned over (app resets, etc) but thats not in the scope of what you asked : )
I've done a search on this subject already, and have found the same data over and over-- a review of the three different types of sessions. (InProc, Sql, StateServer) However, my question is of a different nature.
Specifically, what is the advantages/disadvantages of using the built in .NET session in the first place?
Here is why I am asking: A fellow .NET developer has told me to NEVER use the built in Microsoft Session. Not at all. Not even create a custom Session State Provider. His reasoning for this is the following--that if you have the Session turned on in IIS it makes all of your requests happen synchronously. He says that enabling session degrades the performance of a web server.
His solution to this is to create a session yourself-- a class that stores all values you need and is serialized in and out of the database. He advises that you store the unique ID to reference this in a cookie or a querystring variable. In our environment, using a DB to store the sessions is a requirement because all the pages we make are on web farms, and we use Oracle-- so I agree with that part.
Does using the built in Session degrade performance more than a home-built Session? Are there any security concerns with this?
So to sum it all up, what are the advantages/disadvantages?
Thanks to all who answer!
My experience has been that the session is a good means of managing state when you use it appropriately. However, often times it's misused, causing the "never ever use the session" sentiment shared by many developers.
I and many other developers have ran into major performance issues when we mistakenly used the session to store large amounts of data from a database, so as to "save a trip." This is bad. Storing 2000 user records per session will bring the web server to its knees when more than a couple of users use the application. Session should not be used as a database cache.
Storing an integer, however, per session is perfectly acceptable. Small amounts of data representing how the current user is using your application (think shopping cart) is a good use of session state.
To me, it's really all about managing state. If done correctly, then session can be one of many good ways to manage state. It should be decided in the beginning on how to manage state though. Most often times, we've run into trouble when someone decides to just "throw something in the session".
I found this article to be really helpful when using out-of-process modes, and it contains some tips that I would have never thought of on my own. For example, rather than marking a class as serializable, storing its primitive datatype members in separate session variables, and then recreating the object can improve performance.
Firstly, you colleague is implementing his own DB backed session management system, I do not see what advantage this has over using built in session state stored on a database (MS SQL is the default, there is no reason not to use Oracle instead).
Is his solution better than the built in one? Unlikely. It's way more work for you for a start. Here's a simple illustration of why. Let's say you use cookies to store your ID, how do you cope with a user who turns off cookies? If you are using ASP.Net's session state there's no problem as it will fall back to using the query string. With your colleagues idea you have to roll your own.
There is a very valid question as to whether you shold have session state at all. If you can design your application not to need any session state at all you will have a much easier time scaling and testing. Obviously you may have application state which needs to live beyond a session anyway (simple case beign user names and passwords), but you have to store these data anyway regardless of whether you have session state.
The MS implementation of Session State is not evil in and of itself... it is how some developers use it. As mentioned above, using the built-in session state provider means that you don't have to reinvent the security, aging, and concurrency issues. Just don't start jamming lots of garbage in the session because you're too lazy to figure out a better way to manage state and page transitions. Session doesn't scale really well... if each user on your site stuffs a bunch of objects in the session, and those objects take up a tiny bit of the finite memory available to your app, you'll run into problems sooner than later as your app grows in popularity. Use session in the manner for which it was designed: a token to represent that a user is still "using" your site. When you start to venture beyond that, either because of ignorance or laziness, you're bound to get burned.
You should be judicious in your use of Session, since multiple requests to the same Session object will usually be queued: see "Concurrent requests and session state" http://msdn.microsoft.com/en-us/library/ms178581.aspx.
Note that you can set EnableSessionState to ReadOnly to allow concurrent read access to session state.
This queuing is a good thing, as it means developers can use Session without being concerned about synchronization.
I would not agree with your colleague's recommendation to "never" use Session and I certainly wouldn't consider rolling my own.
First, a browser will only make two requests, to a given hostname, at a given time. For the most part these requests are for static content (JS files, CSS, etc). So, the serializing of requests to dynamic content aren't nearly the issue that one might think. Also, I think this may be confused with Classic ASP, where pages that use Session are definitely serialized, I don't believe this is the case with ASP.Net.
With ASP.Net session state (SQL mode, state server, or custom) you have an implementation that is standard, and consistent throughout an application. If you don't need to share session information this is your best bet. If you need to share information with other application environments (php, swing/java, classic asp, etc.) it may be worth considering.
Another advantage/disadvantage is that there has been a lot of developer focus on the built-in methodology for sessions with regards to performance, and design over rolling your own, even with a different provider.
Are there any security concerns with this?
If you roll your own you'll have to handle Session Fixation and Hijacking attacks, whereas using the built-in Session I think they are handled for you (but I could be wrong).
the home made session as you have described is doing nothing different "SQL" state of .Net sessions and in my experience i dont think session degrades your performance in anyway. building your own session manager will require putting in several other plumbing tasks along - security, flushing it out, etc.
the advantage with in-built sessions is its easy to use with all this plumbing already been taken care of. with "SQL" mode you can persist the session data in database thus allowing you to run your app on web-farms without any issues.
we designed a b2b ecommerce app for fortune 57 company which processes over 100k transactions a day and used sessions [SQL mode] quite extensively without any problems whatsover at all.
Correct me if I am wrong:
The primary advantage of storing Session state in a db, e.g., SQL Server, is that you are not consuming memory resources, but instead storing it to disk in a db.
The disadvantage is that you take an IO hit to retrieve this info from the database each time you need it (or maybe SQL Sever even does some magic caching of the data for you based on recently executed queries?)
In any event, this the price an IO to retrieve the session info from a db per trip to the web server seems like a safer strategy for sites that encounter a lot of traffic.