Understanding Caching in ASP.NET

Usually, Web sites (Web applications) are accessed by multiple users. On certain days, a Web site can experience an extremely low load and, as a result, provide faster access. However, in just a few hours, the load on the site can increase exponentially, resulting in slow access. Slow access is the most common problem that plagues a Web site when it is accessed by a large number of users simultaneously.

However, load is not the only reason why a Web site is slow. Other physical aspects affect speed, such as the type of modem, Internet connection, and telephone line. Therefore, it might not be good business sense to invest in high-grade hardware that handles the entire load just to improve the access speed, because the heavy load is only temporary and not constant.

It would be better if access speeds could be improved without investing in high-grade hardware. In such a scenario, caching provides a solution. Caching is a technique wherein frequently used data and Web pages are stored temporarily on local hard disks for later retrieval. This technique improves the access time when multiple users access a Web site simultaneously or a single user accesses a Web site multiple times.

Caching allows server-side Web applications to scale better, and improves the overall performance of the Web application. Thus, the ASP.NET code does not need to be executed every time to process the same request from multiple clients or from a single client multiple times. This saves on the CPU cycles at the Web server, resulting in improved response time.

Caching, as a technique for improving system performance, is not a new concept. It has been used successfully in various applications, ranging from relational databases such as Microsoft SQL Server to various operating systems. ASP.NET provides a Web cache to store Web objects.
A Web cache is a temporary storage of Web objects, such as HTML documnts, for later retrieval. You can specify the cache location to be on the client or on the server.

The different locations where caching can be performed are described as follows:

Client: To provide improved performance, client applications (like browsers) perform caching by storing data from the Web in temporary files on the hard drive or system memory of users' computers. However, these caches cannot be shared across multiple users.

Dedicated server: Caching can be performed at the server side so that caches can be shared across multiple users on a network. Most administrators use proxy servers, such as Microsoft Proxy Server, to store frequently used Web pages on the hard disk of the proxy server. The proxy server fulfills all the requests for the Web page without sending out the reques to the actual Web server over the Internet, resulting in faster access.

Proxy caches are often located near network gateways to reduce the bandwidth required over expensive dedicated Internet connections. These systems serve many users (clients) with cached objects from many servers.

The Web objects that are requested by one client are stored in a cache, and can be retrieved later when another client requests the same object. For even greater performance, many proxy caches are part of cache hierarchies, in which a cache can enquire neighboring caches for a
requested document, to reduce the need to fetch the object directly.

Such an organization of multiple cache servers is also referred to as a cache array.

Reverse proxy: Caches can also be placed directly in front of a particular Web server, to reduce the number of requests that they receive. This model allows the proxy server to respond to the frequently received requests and pass the other requests to the Web server. This form of proxying is called a reverse proxy, wherein the proxy server is used by the Web server to speed up request processing.

This model is unique in that it caches objects for many clients, but usually from a single server.
After discussing the various locations where caching can be performed, let us now look at some of the most significant advantages of Web caching:

Reduced bandwidth consumption: Because the frequently used data and Web pages are cached and ASP.NET allows developers to configure the cache location to be on the client machine, most requests are fulfilled from the local cache. Therefore, fewer requests and responses need to go over the network between the client and the server. This results in reduced and width consumption.

Reduced server load: Because frequently used data and Web pages are retrieved from the cache, the server does not need to execute the same ASP.NET code multiple times to produce the same output. This saves valuable CPU time at the server end.

Reduced latency: Because most requests do not need to go to the server for processing, the access time improves significantly. Although Web caching provides many advantages, it is one of the most misunderstood technologies on the Internet. Webmasters, in particular, fear losing control of their sites because a cache can hide their users from them, making it difficult to see who's using the sites.

In addition, the number of hits is not counted correctly, because the cache server(s) might fulfill some percentage of client requests.

However, careful planning and proper location of a proxy server cache will help your Web site load faster, and reduce load on your server and the Internet link. The difference can be dramatic; a site that is difficult to cache may take several seconds to load. Users will appreciate a fast-loading site, and will visit it more often.

Another concern related to Web caching is that the caches might serve outdated content.


related post

CREATING ASSEMBLIES WITH ASP.NET

BUILDING HANDLERS IN ASP.NET

INTERFACES AND CLASSES CREATION IN ASP.NET

CACHING IN ASP.NET

CACHING IN ASP.NET PART TWO

WIRE LESS APPLICATION WITH ASP.NET

SECURITY IN ASP.NET PART ONE

SECURITY IN ASP.NET PART TWO

LOCALIZING ASP.NET APPLICATIONS

DEPLOYING ASP.NET APPLICATIONS

ASP.NET CONFIGURATION SYSTEM

WEB SERVICES IN ASP.NET

WEB SERVICES PART TWO

WEB SERVICE INFRASTRUCTURE

WEB SERVICE INFRASTRUCTURE PART TWO

EXCHANGING MESSAGES IN ASP.NET

MICROSOFT HAIL STORM

SOAP AND DOT NET PART ONE

SOAP AND DOT NET PART TWO


No comments:

Post a Comment