Keep stateless Web pages in mind when planning your Web site

Takeaway: Programming stateless Web pages can go a long way in the battle to achieve scalability for your Web site's infrastructure. This article covers the details to keep in mind when designing a stateless model.

The World Wide Web and the HTTP protocol are based upon a stateless model. In a typical network environment, every request that is made is known because there is a constant connection between the server and the client. For a Web server, this is not the case. Each request to a Web server is anonymous and not associated with the previous request. Most Web server products have overcome this limitation by providing methods to maintain client state from request to request. Ultimately, these methods rely on either cookies or URL rewriting to communicate some unique information that helps identify the requests from a given browser.

Session information defined
The information that the Web server or Web application server maintains is referred to as session information . It’s easy to program the session to store state information and refer to that information in future requests. The scalability issue with this method is that for each new client, the session must be established and then maintained for a period of time. Even if the client only requests one page and then closes their browser, the Web server will maintain the session information until it times out. In Java Server Pages and Active Server Pages, this default is 20 minutes.

It is best to avoid storing anything in the session. Deactivating session tracking can significantly increase scalability because most client interactions with Web servers are very short. By not maintaining session information, the Web server can deal with a request and free those resources immediately. If session information is maintained, the memory for that session will not be freed up until the time-out period passes. For a busy site, this limits scalability and requires more RAM in the Web application servers.

Programming stateless Web pages
Programming stateless Web pages requires more effort but will greatly enhance the scalability. Information can be placed in cookies and passed between the client and server with each request. The size of a cookie is limited to 4K, so like all resources in the design, they must be used sparingly to stay within limits. There are also many products and free code that store session information in a database. But don’t look for these solutions to help achieve scalability. Information stored this way causes the application to make a database request for the session data with every page request. That violates a design that is supposed to treat everything as a valuable resource because it overuses network bandwidth and database connections. It is likely that most Web sites have more Web servers than databases, so this idea doesn’t make much sense for scalability.

Security and the proper use of cookies
The design must also consider security when planning methods to maintain stateless connectivity. Some applications require higher security, and that will generally hurt scalability. For instance, running SSL (HTTPS) on Web servers uses much more processing power than standard HTTP. As a general rule, try to put information needed for every page in a cookie and place other information that is not needed for every page in some form of shared storage like a database. Typically, the current user ID is needed for every page and can be easily tracked within a cookie. But the e-mail address of that user probably is not needed on all pages, so it can reside in a database to be called when necessary.

The downside to cookies is that a number of tools exist to assist users with refusing cookies. I generally suggest some cookie support detection and a message to users that they cannot use your site if they do not support cookies. I realize this is a debatable issue, but unless you’re personal information is placed in the cookie, there’s no harm in ensuring the user a quick response by using cookies. The alternative is to use a URL rewrite scheme so that the cookie information is written to the URL. There are several ISAPI filters for Microsoft’s Internet Information Server that take cookies, rewrite them into the URL, and extract them from incoming requests so that the server code still thinks it is writing and receiving cookies. These work fine, but they make the URLs very complicated and ugly.

Load balancing
If the Web site design sticks to a stateless model, the topic of load balancing is a breeze. Load balancing attempts to send user requests to the resource that can most quickly handle them. If session information is maintained on each machine, the requests from a user must go to that machine. Most products that support load balancing will likely support this form of session request. However, this method is fundamentally flawed. Just because the initial request from a user is best handled on machine A does not mean that all future requests by that user should be handled on machine A. This is especially true if machine A suffers a catastrophic failure after the first request by the user and all the session information is lost. Maintaining a stateless design (with cookies or URL rewriting) allows the Web site to more efficiently balance the incoming requests and route those requests to the most appropriate resource.

Summary
Keep this short overview in mind when designing a scalable Web solution. There are many details to juggle when designing robust Web architectures. These principles will help you get those details to the surface.

Have a comment?
Share your comments and additional ideas about software practices to help achieve scalability.  Send the editor an e-mail .