More Group Sites
Education Books
School Rankings
Jobless Net
Better Home

Help | Subscribe/Unsubscribe | Rules | Other Group Sites: Better Education | Better Education Forum
Welcome Guest! To enable all features please Login or Register.



Go to last post Go to first unread
#1 Posted : Saturday, 5 September 2015 11:03:40 PM(UTC)

Rank: Administration


Groups: AcademicCoachingSchool, admin, Administration, BookSeller, CatholicSchool, CoachingAdult, CoachingProfessional, CoachingSports, ExtraCurriculumCoaching, IndependentSchool, Moderator, MusicTeacher, PrivateSchool, PublicSchool, SelectiveSchool, tutor
Joined: 23/11/2008(UTC)
Posts: 521

Session or view state

If the search object isn't huge in size, then go with using a View State. A View State is perfect if you only want the object to live for the current page's life cycle.

A session object is also fine to use, but obviously once the search object is in there, it will be around for longer the page's life cycle.

View state is bandwidth hungry
Session variables are memory hungry as per number of users
Applications variables are shared
Cache is memory hungry as per number of resources
Cookies are the least secure

See details here.

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.)

Source: Which is better for performance viewstate or session

ASP.NET GridView RowDeleting after resorting

Edited by user Saturday, 5 September 2015 11:27:09 PM(UTC)  | Reason: Not specified

Rss Feed  Atom Feed
Users browsing this topic
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.