Which one more costilier View State or Session when a bulk data is stored. Why?
Depends on your point of view and usage, but generally session is cheaper all around.
For the client, session is nearly free. It only has to deal with keeping up with a session cookie (or the session id via the url if you configured for cookieless sessions). Viewstate pushes all the data to the client, in the text of the page source.
For the server, session and viewstate both have a cost. viewstate has to be serialized and deserialized and moved across the wire. Session is stored in memory (unless configured otherwise) but doesn't have to be manipulated. So session uses more storage in memory over a longer period of time, viewstate creates temporary memory use and higher cpu hits. So it depends on how much data, how often the client is communicating with the server, and which resources you want to conserve... though in general, with bulk data, session would win hands-down in almost all practical cases.
ViewState will cost bandwidth and make your pages heftier while the Session will cost memory on the server or some other server if out-of-proc is used.
Related
In this question there's a comment with a few upvotes that states:
InProc session state is known to be highly unstable under load. If it's abused (happens all the time), then Session["foo"] = null will perform better than Session.Remove["foo"]. The garbage collector should clean up the mess of excessive session variables
This concerns me as all of my web apps make heavy use of session state (account info, baskets, payment details, user preferences etc.).
I can't seem to find any evidence to back up this claim, can someone debunk this or explain why this is correct. Am I wrong to be storing such info in session? I'm not looking for a pros and cons of InProc vs SQL, I'm aware of the differences.
All of my apps run on a single or dedicated webserver so I've never seen any benefit or point in moving to SQL for session state.
InProc Session State is stable and you don't have to worry about it. I don't know why he called it unstable but I guess he might have thought one of the following reasons while commenting:
If your application gets too much load; when you scale it, you have to use sticky session (for InProc SessionState) to redirect the requests to the same server for a client otherwise session object would not persist.
If an application has memory leaks or inconsistencies, heavy load will most probably trigger the application to reset and this will cause all the session data be lost so that current users' active pages might get errors since their session datas are lost.
Session object is locked out for the entire request (for that user only) to prevent multiple pages to write into the session so that if concurrent requests are made for example, they have to wait for each other to write data into Session. But it happens both in SQL and InProc SessionState.
I saw banking applications which work with InProc SessionState and there is nothing unstable about it.
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.
After a user has initially established session with ASP.NET, with each subsequent HTTP request how much of StateServer session objects are immediately and automatically fetched and deserialized? For example:
Are ALL session objects fetched the moment the request is received and session re-established, or...
After session is re-established are session objects fetched and deserialized individually as each request to HttpContext.Session["..."] is made?
The answer has a HUGE impact on how I can use session. For example, if I have pre-fetched a significant amount of user data into session, and the StateServer session is completely deserialized upon each HTTP request, then I will experience a noticeable performance hit. If however the pre-fetched user data is only deserialized when I request specific session keys, then for me there is no worry.
UPDATE
After marking an answer to this question, I discovered that ASP.NET with AppFabric Server 1.1 has an option to have session restored on-demand rather than all-at-once. This is controlled by useBlobMode in your web.config.
Session loads all of the user Session information when the page is first loaded. It then persists the users Session information back to the store after the page is done processing.
You can get a better understanding via MSDN on custom state store implementations.
This is a major reason that you're supposed to use Session as rarely as possible because it is expensive to deal with (both in the transporting to and from the data store and the holding of the data in memory for the lifetime of the page request).
I have to store data of thousand of records in a data table and maintained on postback. Which option is suitable for me viewstate(which i used) or session. When i used viewstate it will created hidden field for storing it and slow down the page loading. So is there any overhead (server side memory consumption and delay in the responses) in storing it in session. Please suggest me the solution
For large amounts of data, Session is way more efficient. If you can detect when the user is done with a particular block of data, set the Session variable to null, to help memory overhead. You can't always do this, but the Session will eventually expire and the memory will be reclaimed then. Lowering the Session timeout can help some, but don't set it too small, you don't want to cut off your users. Session needs to be enabled in your Web.config file.
Here's the basic guidelines for Session vs. ViewState:
ViewState: The binary data structure of the ViewState is Base64 encoded to be placed into the page, which means it is 1.3333 times (8/6) the size of the original binary data. This data is uploaded and downloaded for each page view. So if you have a lot in the ViewState it impacts page response times. Base64 encoding is probably highly optimized, so that's not a performance hit. Each page request will allocate, then free up, the space for the ViewState, so it's not a long term memory hit. Since the data is in the page, it doesn't expire.
Session: All of the data in the Session is preserved in the web server between page loads. This keeps the page small, it only has to carry the Session identifier. On the down side, any memory used to store data in the Session stays allocated until the Session expires. I've wondered if the Session copies binary data or just keeps a pointer. Like Base64 encoding, this can be highly optimized, so if it happens it is not a performance hit. The Session may expire, if the user waits too long between page views. If the session expires, it should return the user back to some known state in the web page.
One other issue here, if you're storing information in the Session, the session id may be shared among multiple tabs in the client browser. You have to be careful how you're using the data stored in the Session. Make sure you test for this so your users don't get unexpected results.
(Note: Using ViewState is RESTful, Session is not.)
In our application, we have a "BasePage" that declares a number of properties to be used by more or less every page in the app.
Inside these properties, they write to ViewState. These are all typically an int or small string value, nothing huge. Typical use is call a web service and hold an id for use within the page, for example.
I've used viewstate since I'm wary of the loss of session variables should IIS recycle for example. Also, I figured, very small values would not add hugely to the page size.
Am I being overly paranoid about session though and would it have been a better option.
Our environment is a 2 server cluster with SSL termination on each server, sticky sessions maintained by the load balancer - so using In Proc is not a problem per say, I'm just very wary of it.
Never trust your user sent data.
Even all data you receive is not sensitive, if you send it to your user browser, you should to check it again before use it. Maybe most users are legitimate, but just one can break your application.
What are your options to store data?
Hidden field; can ve easily tampered at client side
Cookie; ancient method to keep user specific data, but very size limited.
ViewState; your data go to client and come back, using bandwidth and could be tampered.
Session, InProc; your never have problems, until a application pool get recycled
Session, State server; you keep your session data in another server process.
Session, database; can work with almost (if not all) load balance scenarios, as you dont need stick sessions, nor to worry with app pools recycling. All your data are belong to us your SQL Server.
Reading your scenario, you probably need to deal with out-of-process session storage.
I think it's best to avoid using Session state where possible, especially on a server cluster even if you are using sticky sessions. Sessions can expire, or disappear when IIS recycles (like you said).
I'd go with keeping the values in ViewState or a cookie.
If it is not sensitive data, I would also prefer to store it in the HTML rather than the session.