There are several ways to achieve higher performance and better scalability in ASP.NET. One way is through the use of caching. Caching is a technique whereby frequently requested data is stored in a quickly accessible location, so that the next time the same data is requested, it can be quickly fetched from the cache location rather than regenerated by the application.
This can result in a significant performance boost, especially for dynamically generated content such as ASP.NET web pages and components, and in cases where the data underlying the response is expensive to gather, such as database queries.
Most web browsers cache pages received so that if the same page is requested again, it does not have to be sent over the Internet, but rather is retrieved directly from the local hard drive. Most operating systems also employ caching of some sort to store frequently requested data in memory, rather than require additional hard drive reads.
The only caching this chapter will be concerned with is server-side caching performed by the .NET Framework.
In some respects, caching is similar to the storage of state objects. (See Chapter 6 for a complete discussion of state in ASP.NET.) In both cases, data is saved for use across multiple requests, and in the case of application state, across multiple sessions. However, there the similarity ends. With state objects, the developer explicitly saves a particular piece of data in a particular place, intending to be able to retrieve that data at any time later in the session or in other sessions. The data stored in state objects will last as long as the session or application, and will not be lost until the developer specifies it is to be removed or replaced. In short, the developer can count on the data in a state object being available.
In contrast, cached data is non-deterministic. You cannot assume that any piece of data you are looking for will be in the cache. As will be shown later in this chapter, whenever your program attempts to retrieve data from the cache, it must test to see if the data is there, and make provisions to retrieve the data elsewhere if it is not present in the cache. The data may be missing because its lifetime expired, because the application needed to free memory for other purposes, or simply because the cache was never populated.
There are several different types of caching present in ASP.NET. Some are automatic and require no intervention on the part of the developer, while others require explicit coding.
When a
web page or web service
(.aspx or .asmx file,
respectively) contains all its code inline, then that code is
compiled into a page class the first time the page or service is run.
This causes some delay, but that compiled class file is then cached
on the server and is called directly every subsequent time the page
(or service) is referenced. This is done automatically -- there is
no user or developer interaction required for this to happen.
The CLR watches for source code changes. If the source code changes, the CLR knows to recompile the next time the page or service is called.
Application-wide configuration information is contained in the configuration files. The specifics of configuration will be covered in detail in Chapter 20. For now, the relevant point is that when the application is started, i.e., the first time a page or service is called from the application virtual root directory, all the configuration information must be loaded. This can take some time, especially if the configuration files are extensive. Configuration caching allows the application to store the configuration information in memory, thus saving time when the information is subsequently needed.
Output caching is the caching of pages or portions of pages that are output to the client. This is one of the main performance enhancing techniques available to the developer. Since the page does not have to be recreated from scratch each time a request is made for it, the web site throughput, measured in requests per second, can be significantly increased.
Cached pages or portions of pages are stored on the server’s hard drive. Subsequent requests for the same page or portion of page are fulfilled directly from the hard drive, rather than recreated by the page’s program logic. Since hard drive space is usually not at a premium, output caching scales well.
Output caching will be covered in the next section of this chapter.
Object caching is the caching of objects on the page, such as data bound controls. In contrast to output caching, object caching stores the cached data in server memory. Since server memory is a limited resource, object caching must be used more carefully than output caching to avoid scaling problems.
Object caching will be covered in detail later in this chapter.