Three kinds of session state information: (1) sensitive (2) non-sensitive (3) cached
Several strategies can be used to manage session state data, but each has limitations: in-process state management, synchronized state management, and leveraging the state management possible on the client.
in-process state management that ASP.NET provides. This approach performs well if there is only one server in the farm. However, this issue can be mitigated if the load balance is set for sticky sessions. A sticky session setting keeps users on one server, reducing the probability that a user will transition from one server to another and not have their state information available. The main concern with the approach of keeping the session data in in-process memory is that transitioning to another state management approach is difficult because every other form of session management requires that the object be realizable.
synchronized state management, all session information is stored and retrieved from a centralized
location. This solves the potential problem of having out-of-sync information across servers. There are two approaches to a synchronized, or centralized, state management. The first approach to synchronized state management is to use an in-memory cache, but the problem with it is that at some point the server managing the information must be rebooted. The second approach is to use a database for synchronization, but the database induces delay and its own performance problems.
server-client, you transmit the state back to the client. The challenges with this strategy are that sensitive information must be encrypted (adding overhead), and that the link speed between the server and client is typically the slowest part of the system.
SharePoint and Memory
Every SPSite or SPWeb object is approximately 2MB in size.
SharePoint can implement two key types of in-memory cache: (1) output caching (2) object caching.
Output caching is an ASP.NET feature that can be configured in SharePoint to provide caching of the
output of Web pages. In this process, the page is processed only once and returned so that second user to access a page receives a copy of what executed when the first user came to the page. Output caching is appropriate for anonymous sites but not appropriate when the page has personalized content. In addition to returning the pages to the user more quickly for the second and subsequent requests, output caching reduces the CPU and database load on the farm because the requests aren’t being processed repeatedly.
However, this comes at the expense of a greater amount of memory being required on the server to
support the additional caching.
Object caching operates at a data level and is designed to improve performance of data operations. The object level cache can be a substantial improvement in scalability and performance. However, just like the output cache, the object cache consumes memory—memory that might be necessary for other operations.
From a session state perspective, SharePoint Server creates and configures a shared SQL session state
database, providing for synchronized session state. Because of this, an additional SQL Server load is placed for each object added to the user’s session state. SharePoint Foundation will, by default, not use session state.
This blog gives very important info about .Net
ReplyDeleteVery nice Thanks for sharing Dot Net OnlineTraining Hyderabad
wonderful article. Very interesting to read this article.I would like to thank you for the efforts you had made for writing this awesome article. This article resolved my all queries. keep it up.
ReplyDeleteDot Net Training in Chennai | Dot Net Training in anna nagar | Dot Net Training in omr | Dot Net Training in porur | Dot Net Training in tambaram | Dot Net Training in velachery