HTTP is stateless, means that the web pages don’t know if the requests are from the same client and pages are recreated and destroyed every trip to the server. Therefore, state management is important for web applications.
All data that needs to be available to the application across different requests within the same session is called session state or session state data. For storing such data between requests, there are in general two possibilities:
· Sending the state information back to the client. With the next request the current state is transmitted to the server again.
· Keeping the necessary data structures on the server. No session data (except the referencing identifier) is transmitted to the client.
1.1.1 Drawbacks of managing state information in client
· Sending the session state data back to the client is generally not recommended. From a security perspective, the main problem is that the session state can easily be manipulated on the client side if it is not protected appropriately.
· In scenarios where session state information must be transmitted back to the client, it is generally possible to sign all transmitted session state information in order to prevent changes on the client side. When the server receives session state information within requests from the client, it can check the signature in order to verify that the data was not altered.
· A functional drawback is that the size of the information that can be stored by round-tripping it to the client side is limited through the available bandwidth. For session state data that consists of only a few bytes this does not matter. However, in scenarios with larger session state data structures, re-transmitting them with each request becomes impractical.
1.1.2 State management in server
Keeping the session state strictly on the server is the recommended solution.
· Session state is stored in the server RAM.
· Session state is serialized and written to a persistent storage.
· Storing mechanism for session is irrelevant from a session management security point of view.
· Ensure that the session state information is sufficiently protected against illegal access on the server side.
1.1.3 Session IDs
Typically, the process of managing the state of a web-based client is through the use of session IDs. Session IDs are used by the application to uniquely identify a client browser, while background (server-side) processes are used to associate the session ID with the existing state of the user. Session state management is a key element of Web application design. ASP.NET contains a session state support service that is flexible and scalable.
1.2 Methods of implementing Session States in ASP .NET
There are three session state modes for ASP.NET Applications. Each mode offers varying degrees of performance and scalability as described in the following list:
1.2.1 InProc
The in-process store provides the fastest access to session state. There is no serialization or marshaling costs involved because state is maintained within the managed memory of the ASP.NET process. When the process recycles, the state data is lost, although we can disable process recycling in IIS if process recycling affects the application.
Drawbacks:
· Limits application scalability
· Cannot use it in conjunction with multiple worker processes.
· Also, high numbers of large or concurrent sessions can cause application to run out of memory.
1.2.2 State Server
The session state service, a Microsoft Win32® service, can be installed on local Web server or on a remote server that is accessible by all Web servers in a Web farm.
Advantage:
· High Scalability.
Limitation:
· Performance is reduced in comparison to the in-process provider because of the additional serialization and marshaling that is required to transfer the state to and from the state store.
1.2.3 SQL Server:
Microsoft SQL Server provides a highly scalable and easily available solution. SQL Server is a solution that is well-suited to large amounts of session state.
The serialization and marshalling costs are the same as the costs for the session state service, although overall performance is slightly lower.
SQL Server provides clustering for failover, although this is not supported in the default configuration for session state. To enable clustering for failover, we have to apply configuration changes, and the session data must be stored in a non temporary table.
1.3 Administering Session states in server
Developers can use Session state in applications and leave the implementation up to the administrators. When developer creates an ASP.NET application on his development machine, he can use in-process session state. Then when the application is deployed to a production server Web farm, an administrator can change session state to use either the ASP.NET State service or to host the session data in SQL Server. All of these options are transparent to the application. A simple setting in Web.Config makes the change in session state.
If your application does not require the ASP.NET session state services, turn it off. You can do this on a single page or for an entire application. You can disable session state in a page by adding EnableSessionState="false" in the Page directive like this:
<%@ Page Language="C#" EnableSessionState="false" AutoEventWireup="false" Codebehind="WebForm1.aspx.cs" Inherits="WebApplication2.WebForm1"%>
You can also totally disable session state for an application by setting mode=”Off” in Web.Config like this:
sqlConnectionString="data source=127.0.0.1;user id=sa;password="
cookieless="false"
timeout="20" />
1.4 Why web farms?
Scalability and high availability is the answer.
Once a web application has gained enough business traction to be handling thousands of concurrent users and hundreds of requests per second, it inevitably bumps up against the performance limits imposed by running on a single server.
1.4.1 Performance limits of a single server:
· Even we do caching, session state accumulate to the point where they tax available memory, causing frequent processor-intensive garbage collection events and even recycling of worker processes, with loss of in-memory data.
· The available ASP.NET threads become exhausted and requests start to queue, eventually leading to error conditions.
· The server may not be available to fulfill the request all time.
The solution is to spread the load across clustered application servers, usually referred to as a “web farm.”
The move from a single server to a web farm often causes significant disruptions, unless the application has been architected from the beginning to support load-balanced clustered request processing. Without explicit planning, many applications end up with hidden dependencies on resource affinity.
1.4.2 Resource affinity is ASP.NET Applications in web farms:-
“Resource affinity” refers to a requirement for code to run on a particular thread, CPU, component instance or server. The Session is a resource. The most common affinity problem in ASP.NET applications is the use of in-process session state, which assumes that all requests from a single user session will be processed on the same web server.
1.4.3 Resolving session affinity in ASP.NET Applications in web farms:
· Route all requests to the server where the session originated. This significantly reduces load balancing efficiency, and it impairs the ability of the ASP.NET application to tolerate failures such as recycling the worker-thread process under extreme load.
· Storing session state in a shared location, this can be accessed by any of the web servers in the farm.
1.4.4 Session sharing in web farms:
ASP.NET has built-in support for storing session state out-of-process, either in a database or in the memory space of a designated state server.
Advantage:-
· By moving session state out-of-process, the dependency of a given user on a given web server is reduced: if that web server fails or recycles, the user’s current session data is not lost.
1.5 Implementing out-of-process session state storage
For out-of-process state storage to be possible, all .NET objects stored in session state must be serializable. Because .NET classes are not serializable by default, this often means recoding, either to add attributes to user-defined classes or to use serializable built-in classes instead of ones that are not serializable.
1.5.1 State Server
State Server is simple, free software available with ASP.NET for storing session state data. It can be run directly on the web server, at least providing protecting from worker-thread recycling, or it can be run in a central location to get the full benefits of non-affinity.
Limitations of State Server:
· When using State Server remotely—every request/response pair involves two trips to the State Server, one to retrieve the session state data at the beginning of the generation of the response and another to return the modified session state data when the response is completed.
· When it fails or restarted all the session data is lost
1.5.2 SQL Server
SQL Server is a popular choice for out-of-process session state storage.
Advantages:-
· The application is already using SQL Server for retrieval and storage of data related to the application.
· High availability features such as clustering to protect session state data in case of failure.
Limitations:
· The performance of SQL Server is even slower than that of State Server.
· SQL Server is designed to be a highly reliable and secure transactional database, so the processing of session data takes significantly longer.
· SQL Server also requires the same extra pair of network trips that State Server does: at the beginning and end-of-page processing.
No comments:
Post a Comment