Benefits of Maintaining State: Performance and Scalability
As a Web Application's user community grows, there is an ever-growing amount of stress placed on the Web Server as it attempts to accommodate this larger volume of calls. As more stress is placed on a Web server, the performance will take a hit. A slow Web Service, like a slow Web site, will not only waste expensive company resources, but it can potentially drive customers away, causing even greater losses. When you design and implement a high-performance Web Service, it is extremely important to carry out performance tuning. There is no set recipe for improving the scalability or the performance of a Web Service. Some tweaking may need to be performed in various places within the Web Service. The balance between scalability and performance can be delicate, which is why the term performance tuning is so appropriate.
The following are some of the important goals that should be taken into account:
Conserving CPU cycles— Keep the volume of operations performed by the Web server hosting the Web Service to a minimum.
Conserving time— Keep turn-around time on the Web server to a minimum by reducing the number of calls to the database. Also, make sure that the code is optimized and performs well.
Conserving resources— Keep the amount of reserved memory on the Web server to a minimum.
As you may have noticed from the previous list, performance tuning is almost like nature preservation (conserve, conserve, conserve…)—the more we save, the better it is for humankind! Unlike nature preservation (where the more you do for the environment, the better it is), when dealing with improving the scalability and the performance of a Web Service, we need to find an optimal point and stop there. This is due to the fact that scalability and performance go hand-in-hand for most of the time, but there are times when this is not the case. Improving performance will almost always improve scalability, but the reverse is not always true—sometimes, improving scalability can have a negative effect on performance.
Improving Performance
A typical application receives data from a back-end system, manipulates that data, and then presents it to the user. Regardless of the speed of a database server, retrieving data from memory will always be much faster than retrieving from a database. Performance can be improved by caching frequently used data on the Web server. This can either be in memory or on disk. You can think of caching as a space-versus-time tradeoff. If the correct data is cached, there will definitely be a performance gain. If too much data is cached, a performance gain is not guaranteed; sometimes the exact opposite could occur because too many resources have been allocated for caching.
Enhancing Scalability
Scalability can be enhanced by making sure that the application can handle an ever-growing user community. So how can state management help to enhance scalability? Instead of making calls to a database every time, you should develop your applications such that frequently used information is retrieved from cache. This would improve the performance by reducing the time needed to retrieve the data. If a method call's performance is improved, the Web Service can serve more users in less time and, as a result, scalability has been improved too. Figure 9.1 contrasts the data retrieval time for uncached and cached data.
Figure 9.1. To cache or not to cache?
Of course, we should not oversimplify the relationship between scalability and performance. Take for example an application that caches 50KB of data per user. If the application has 10 users, almost half a megabyte of memory is reserved for this cache. Now consider 1000 concurrent users using that same application; the cost will be almost 50MB of reserved memory! Of course, with the price of memory today, more and more memory can be “thrown” at a single server. This example is intended to demonstrate the effect that an increasing number of users and their maintained state have on the server's available memory.
The outcome of this would be reduced performance and eventual crash of the Web server.
Although each one of the conservation measures mentioned previously should be weighed according to the nature of the Web Service, we will not discuss them all here. This chapter will focus on two of the important issues—preventing unnecessary roundtrips to the server and keeping turn-around time to a minimum. One of the ways of preventing roundtrips to a server, for example an application server or a database server, is to maintain state on the Web Server.
Facilitating Web Farms
To accommodate a growing number of users and give each one a satisfactory level of responsiveness, the Web application needs to be scalable. One method of scaling a Web application is to throw additional hardware at the problem.
For example, one solution is to upgrade the Web Server to a computer with a faster CPU or multiple CPUs. This solution, known as scaling-up, will provide a new computer that will have the ability to handle a larger number of requests. At some point, this solution will become extremely expensive.
Another hardware solution is to add new processors spread across multiple machines, thereby dividing the workload among multiple machines. This solution is known as scaling-out and, at a certain point, becomes much more cost-effective. In actual fact, what this solution creates is a Web Farm. A Web Farm consists of a number of Web Servers that are situated on a number of machines with the same Web Application residing on each Web Server.
One of the issues that was a big problem with state management and scalability when the Web Server needed to be scaled out was if state is managed on the same Web Server as the Web Service (or page) being requested, a problem might occur the next time a Web Service is requested. There is a good chance that the next request to a Web Service or even the same Web Service may not be hosted by the same machine as the previous request. This would mean that the state that was maintained in the previous request would not necessarily be available for the current request. Later in this chapter, in the “Using the ASP.NET State Service” section, we will see what functionality has been added to ASP.NET to allow us to successfully manage state in a Web farm.