StateMirror: A better state management solution

White Paper

Why state management?

• shopping cart data;
• online banking sessions;
• user workflow state in enterprise applications;
• travel itineraries on travel sites;
• intermediate calculation results.

Although this worked in the early days of the Internet, the industry soon posed a new challenge. User session information sent to the client and back can be sensitive or large in size. Plus, submitted state information may not be relevant anymore, such as a shopper with several browser windows open. Server-side session management accommodates applications that need to store user session data on the server.

This sounds pretty simple until we consider a web farm scenario, where different HTTP requests from the same user may be processed by different web servers. Somehow, all web servers in the farm must have read/write access to the most up-to-date session state information. The trivial solution is to store session state on a dedicated machine that can be accessed by any of the web farm servers for reading or writing session state data.

Imagine if that dedicated machine unexpectedly goes offline. Dozens of users lose the changes they have made during the last couple of minutes. Hundreds of users suddenly end up with empty shopping carts. Thousands of users start getting quite unexpected results.

Or consider a less dramatic scenario: new machines are added to the web farm, and the dedicated state server cannot process all the read/write requests from web servers. The IT department decides to upgrade state server machine, but downtime is unavoidable.

Standard solutions

Let’s see what options available for the IT departments that use Microsoft ASP.NET technology.

Sticky sessions

Sticky sessions cause the load balancer to use the same web server for each request from a certain user. Every user has exactly one copy of session state object on one of the web farm servers.

This solution is prone to:

• potentially uneven load balancing: some web servers may experience high load, and the others handle just a small amount of user requests;
• single point of failure when one web server goes down, all users on this server lose their session state data.

ASP.NET state server

The drawbacks are:

• single point of failure: when state server goes offline, all users lose their session state data;
• limited scalability due to limited memory pool and CPU resources.

With ASP.NET 2.0 Microsoft allows for state server partitioning, so one web server may use a number of state servers for storing session state. But this solution:

• does not eliminate single point of failure;
• requires programming or a third party solution that uses this mechanism.

SQL Server

The drawbacks are:

• again, single point of failure;
• limited scalability due to SQL Server I/O bottleneck.

StateMirror approach

All web servers have StateMirror Client installed. A number of machines in the local network run StateMirror Server.

Every time a web server receives an HTTP request from a user, it checks if the user already has an associated session object. If not, the web server creates a new session object and processes the request. Otherwise, the web server sends a request for session state information to all StateMirror servers, and gets the session state object from the least loaded state server.

When HTTP request processing is done, the web server stores updated session state info on at least two StateMirror servers.

Also, StateMirror Client caches session state information in web server’s memory and re-uses it when the next HTTP request comes from the same user. This feature may dramatically increase solution performance if the read/write ratio for the session state is high enough.

If session state does not change during HTTP request processing, StateMirror Client skips writing it to the state servers, saving CPU resources and local network bandwidth.

If oneof the state servers suddenly becomes unavailable, StateMirror Client takes a copy of the session state data from one of the state servers still online. And when writing an updated session state back to the state server pool, StateMirror Client ensures that more than one copy of the session state data is present in the system. If none of the StateMirror Servers has a copy of this data yet, StateMirror Client chooses the least loaded server to store a copy of data.

When StateMirror server goes offline for a short amount of time, ’outdated’ copies of the session state data may appear in the system. StateMirror Client can resolve these kinds of conflicts.

StateMirror activity can be monitored using a GUI administration tool, StateMirror Explorer. StateMirror Explorer provides information about all active connections between StateMirror Servers and Client. It can also perform basic administration functions such as stopping and starting StateMirror servers and changing their settings on the fly.

StateMirror components

StateMirror Server

State Mirror Client

StateMirror Explorer

Why StateMirror?

• performance: all data is stored in memory;
• scalability:
  • multicast requests are used, no multiple peer-to-peer data transfer;
  • multiple StateMirror servers can be added as needed to store all session state data;
• no single point of failure;
• manageability: easy installation, GUI monitor application, centralized event logging, clear upgrade path;
• flexible pricing depending on the number of the state servers.

To put it simply, StateMirror is a next-generation ASP.NET state server.