State-Management Issues

State management is an important issue whenever you are designing large-scale websites. Most system designs tend to shy away from maintaining any state on their websites because of the complexities involved when scaling out. Let’s take a look at the issues that seem to come up repeatedly.

What Are the Issues?

Scalability is a common issue when designing websites. You can use ASP session state on a web farm in a number of ways. Many companies use routers that use sticky IP, to make sure that each request from a user is routed to the right server and to ensure that session information can be maintained. This seems like a costly method to be able to maintain session state.

The current limitations with ASP session state revolve around three areas:

• Host dependence

• Scalability limitations

• Cookie dependence

To use session state, a user must return to the same host or computer where the information is maintained because this information is maintained in memory and is directly related to the process that it is running.

This brings up the next point: scalability limitations. If the session state is maintained in memory, how can you scale up to handle more traffic? You could always throw more hardware at it, but for how long and at what cost? The preferred method is to use a server farm and some sort of load-balancing appliance, such as Big 5 or Cisco’s Load Director. With this type of setup, the load-balancing appliance will distribute the request to the servers with the least amount of load. Just by adding one server, you can cut the load on your website in half. Not only have you decreased the load , but you also now have fault tolerance designed into your architecture.

Now we get to the cookies issue. Without cookies enabled, session states are very difficult to implement. This is not necessarily such a terrible problem, but it’s one that should be addressed.

ASP.NET Session State

Let’s look at the three issues identified previously in the light of ASP.NET’s solution.

Microsoft has solved these problems in ASP.NET by separating the session state into two different modes: in-process and out-of-process. In-process is the old method of state management, and out-of-process is new to .NET.

Why is Microsoft telling you that session variables are okay to use in a scalable architecture? With Microsoft’s new .NET Framework, you can use session states in a server farm. How is this possible? Microsoft has added alternative session-management solutions. In addition to the existing session-state management, two more ways exist to manage session data. Now you can store the user’s session data in memory on a shared server, and you can store the information in SQL server 7.x or 2000 as well. Take a look at where all this is configured . In the Web.Config file, you will have a section that looks similar to Listing 14.20.

Listing 14.20. Web .config

<configuration> 
   <system.web> 

<sessionState 
             mode="SqlServer" 
             stateConnectionString="tcpip=127.0.0.1:42424" 
             sqlConnectionString="data source=127.0.0.1;user 
id=sstate;password=" 
             cookieless="false" 
             timeout="20" 
          /> 
   </system.web> 
</configuration> 

If you look at the sessionState section in this listing, you will notice that the web server has been set up to maintain session information in a SQL server database. (One thing to keep in mind when using the SqlServer mode is that you shouldn’t use the system administrator account.) Next, you’ll take a more detailed look at the parameters that are used in the Session State section.

Session State Section Parameters

Looking at all the parameters used in the session-state section will help you to identify some of the additional features that have been added to the .NET framework. Table 14.2 lists all the available attributes and parameters for the Session State section.

Performance and Reliability Considerations with ASP.NET Session-State Modes

When you’re building a website, two items should always be at the top of your list: performance and reliability. If your site is slow, no one is going to want to take the time to navigate through it. If your site is down or constantly producing errors, then your customers will find what they need somewhere else. Let’s look at session-state modes with these concepts in mind.

In-Process

If you have a small website and don’t plan to scale up, this is the fastest, most common method of maintaining a session state. If you use this mode, the client must always return the original web server in which it made its first request. This is because the session information is stored in memory, on the server from which it made the request. This mode is best suited for a single server.

Out-of-Process

If you are looking for a more scalable solution without losing too much performance, then out-of-process mode will be better suited for your architecture. You still get the benefit of maintaining the session-state information in memory, but it is stored on a separate process, which is shared by all your web servers in a web farm. One thing that you might want to consider, though, is what happens if the server that maintains the out-of-process session data goes down?

SQL Server 7. x and 2000

If performance is not your top priority and you’re more concerned with reliability, this is your best solution. Because all the session data is maintained in a SQL server, your data is stored in a persistent location.What if the server fails? You can set up the SQL server in a clustered solution for redundancy. Granted, this solution involves a lot more overhead, but it is definitely the most reliable.

These new options are great and open up a whole area of functionality that was once considered taboo. Just remember not to go overboard with session data; it still has to be maintained somewhere, whether it is in local memory or remotely. This is data that is either taking up memory or being marshaled back and forth between computers.