ASP.NET has introduced various new features to the server-side programming model. These new features have made it easier to cache application data, and hence enhance the performance of Web applications. For example, unlike classic ASP, wherein the code is interpreted, all code in ASP.NET is compiled before execution, resulting in huge performance gains.
After the code for an ASP.NET Web page is compiled, all future requests for that page are handled by the compiled code without requiring any recompilation until a change is made to the original ASP.NET page. Also, when a page is accessed for the first time, the code is compiled depending on user needs. For example, if there are 10 functions in an ASP.NET Web page, only those functions are compiled into native machine code, which are needed to respond to a user's request.
Compilation is a two-stage process in the .NET Framework. First, the code is compiled into the Microsoft Intermediate Language (MSIL). Then, the MSIL is compiled into native code during execution. The entire code in an ASP.NET Web page is compiled into MSIL when the solution is built.
However, during execution, only the portions of the code that are actually needed will be compiled into native code. In addition, the configuration of an ASP.NET Web site is loaded from the Web.config file and stored in a memory cache, thereby preventing expensive disk read operations when a configuration value needs to be retrieved.
ASP.NET provides several caching mechanisms that enhance the performance of Web applications. One of the caching mechanisms involves compiling the ASP.NET page and caching the instance on the server. Afterward, the page can be directly retrieved from the cache. The page in the cache is updated only when a change occurs in the page or when the caching period expires.
Expiring of an object from the cache refers to the object being removed from the cache. When the cache expiry for an object is reached, future requests for that object cannot be fulfilled from the cache. In such a situation, the object needs to be retrieved from the actual Web server, or the code behind file for the ASP.NET page needs to be executed again.
ASP.NET supports two types of expiration policies, which determine when an object will be expired from the cache.
These two policies are described as follows:
Absolute expiration: Determines that the expirations occur at a specified time. Absolute expirations are specified in full-time format (hh:mm:ss). The object will be expired from the cache at the specified time.
Relative expiration: Determines that expirations occur after the specified time window has passed. Relative expiration is specified in seconds. After the specified number of seconds, the item is automatically expired from the cache.
The next few sections describe the Cache API and the Cache Performance Monitor counters. Cache API ASP.NET uses the .NET Framework classes to control the caching services. The caching services are encapsulated in the classes contained in the System.Web.Caching namespace. For example, the Cache class is used for explicitly managing an application cache, and the CacheDependency class is used to define and track dependencies of cache objects.
HttpCachePolicy
The complete implementation of cache policies provided by ASP.NET is encapsulated in the HttpCachePolicy class. Applications that want more control over the HTTP headers related to caching can directly use the functionality provided by the HttpCachePolicy class. This class is used to set the expiration time for cached content in relative or absolute time. This class contains methods that are used by ASP.NET to enforce any expiration policies set by the user.
Some of the public properties and methods include in the HttpCachePolicy class are described as follows:
VaryByHeaders: This property represents the list of HTTP headers used to vary the cache output. The ASP.NET cache can maintain different versions of the same Web page if the HTTP headers received in the request are different. This property, therefore, is used to control the HTTP headers that should result in caching multiple versions of the same Web page.
VaryByParams: This property represents the list of parameters received in a Get or Post request. ASP.NET maintains multiple versions of a Web page if the parameter(s) specified in this property vary.
SetCacheability: This is an overloaded method, which sets the Cache-Control HTTP header. Further, the Cache-Control HTTP header controls how documents are to be cached on the network.
SetExpires: This method sets the Expires HTTP header to an absolute date and time.
HttpCacheability
HttpCacheability is an enumeration of all the possible values for the Cache-Control HTTP header. The Cache-Control HTTP header determines whether or not the output is cached. It also determines the location, such as the Web server, proxy server, or a client machine, where the output is cached. The default cache location is the client machine.
The following are the available values in the HttpCacheability enumeration:
NoCache: Indicates that the output will not be cached at any location.
Public: Indicates that the output can be cached on the proxy server as well as on the client side.
Private: Indicates that the output can be cached only on the client side. This is the default value.
Server: Indicates that the Web server will cache the output and the clients and proxy servers will receive a no-cache HTTP header value.
@OutputCache
This page-level directive in an ASP.NET page is used to control the cache duration of the page output. To control the cache behavior of an ASP.NET page, you can use either the @OutputCache directive or the HttpCachePolicy class. However, if the ASP.NeT page is parameterized by using QueryString parameters or the Post method, the page cache needs to be maintained by setting the VaryByParam attribute.
HttpCacheVaryByParams
When the output generated by an ASP.NET page depends on the parameters passed by using QueryString or the Post method, it requires ASP.NET to maintain multiple versions of the same page. The HttpCacheVaryByParams class is used to maintain multiple versions of the same ASP.NET page in the cache. When the VaryByParam attribute is set with the @OutputCache directive in a page, ASP.NET internally uses the HttpCacheVaryByParams class.
Most Web sites today use dynamic Web pages, which present information depending on user preferences. This approach requires a template page, such as an ASPX page, to be used by Web applications. When a Web page is presented to a user, the data retrieved from a data store is dynamically merged into the template and displayed to the user. Although this approach allows the same page to be tailored dynamically to incorporate user preferences, it has certain problems. These dynamic Web pages are less scalable.
Storing frequently requested data in memory variables on the server side is a familiar concept for ASP developers. In classic ASP, two intrinsic objects, the Session object and the Application object, are used to store application data in memory variables. The Session and Application objects are available in ASP.NET, but their functionality is not enhanced much. ASP.NET encapsulates the application data caching in the Cache class.
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
After the code for an ASP.NET Web page is compiled, all future requests for that page are handled by the compiled code without requiring any recompilation until a change is made to the original ASP.NET page. Also, when a page is accessed for the first time, the code is compiled depending on user needs. For example, if there are 10 functions in an ASP.NET Web page, only those functions are compiled into native machine code, which are needed to respond to a user's request.
Compilation is a two-stage process in the .NET Framework. First, the code is compiled into the Microsoft Intermediate Language (MSIL). Then, the MSIL is compiled into native code during execution. The entire code in an ASP.NET Web page is compiled into MSIL when the solution is built.
However, during execution, only the portions of the code that are actually needed will be compiled into native code. In addition, the configuration of an ASP.NET Web site is loaded from the Web.config file and stored in a memory cache, thereby preventing expensive disk read operations when a configuration value needs to be retrieved.
ASP.NET provides several caching mechanisms that enhance the performance of Web applications. One of the caching mechanisms involves compiling the ASP.NET page and caching the instance on the server. Afterward, the page can be directly retrieved from the cache. The page in the cache is updated only when a change occurs in the page or when the caching period expires.
Expiring of an object from the cache refers to the object being removed from the cache. When the cache expiry for an object is reached, future requests for that object cannot be fulfilled from the cache. In such a situation, the object needs to be retrieved from the actual Web server, or the code behind file for the ASP.NET page needs to be executed again.
ASP.NET supports two types of expiration policies, which determine when an object will be expired from the cache.
These two policies are described as follows:
Absolute expiration: Determines that the expirations occur at a specified time. Absolute expirations are specified in full-time format (hh:mm:ss). The object will be expired from the cache at the specified time.
Relative expiration: Determines that expirations occur after the specified time window has passed. Relative expiration is specified in seconds. After the specified number of seconds, the item is automatically expired from the cache.
The next few sections describe the Cache API and the Cache Performance Monitor counters. Cache API ASP.NET uses the .NET Framework classes to control the caching services. The caching services are encapsulated in the classes contained in the System.Web.Caching namespace. For example, the Cache class is used for explicitly managing an application cache, and the CacheDependency class is used to define and track dependencies of cache objects.
HttpCachePolicy
The complete implementation of cache policies provided by ASP.NET is encapsulated in the HttpCachePolicy class. Applications that want more control over the HTTP headers related to caching can directly use the functionality provided by the HttpCachePolicy class. This class is used to set the expiration time for cached content in relative or absolute time. This class contains methods that are used by ASP.NET to enforce any expiration policies set by the user.
Some of the public properties and methods include in the HttpCachePolicy class are described as follows:
VaryByHeaders: This property represents the list of HTTP headers used to vary the cache output. The ASP.NET cache can maintain different versions of the same Web page if the HTTP headers received in the request are different. This property, therefore, is used to control the HTTP headers that should result in caching multiple versions of the same Web page.
VaryByParams: This property represents the list of parameters received in a Get or Post request. ASP.NET maintains multiple versions of a Web page if the parameter(s) specified in this property vary.
SetCacheability: This is an overloaded method, which sets the Cache-Control HTTP header. Further, the Cache-Control HTTP header controls how documents are to be cached on the network.
SetExpires: This method sets the Expires HTTP header to an absolute date and time.
HttpCacheability
HttpCacheability is an enumeration of all the possible values for the Cache-Control HTTP header. The Cache-Control HTTP header determines whether or not the output is cached. It also determines the location, such as the Web server, proxy server, or a client machine, where the output is cached. The default cache location is the client machine.
The following are the available values in the HttpCacheability enumeration:
NoCache: Indicates that the output will not be cached at any location.
Public: Indicates that the output can be cached on the proxy server as well as on the client side.
Private: Indicates that the output can be cached only on the client side. This is the default value.
Server: Indicates that the Web server will cache the output and the clients and proxy servers will receive a no-cache HTTP header value.
@OutputCache
This page-level directive in an ASP.NET page is used to control the cache duration of the page output. To control the cache behavior of an ASP.NET page, you can use either the @OutputCache directive or the HttpCachePolicy class. However, if the ASP.NeT page is parameterized by using QueryString parameters or the Post method, the page cache needs to be maintained by setting the VaryByParam attribute.
HttpCacheVaryByParams
When the output generated by an ASP.NET page depends on the parameters passed by using QueryString or the Post method, it requires ASP.NET to maintain multiple versions of the same page. The HttpCacheVaryByParams class is used to maintain multiple versions of the same ASP.NET page in the cache. When the VaryByParam attribute is set with the @OutputCache directive in a page, ASP.NET internally uses the HttpCacheVaryByParams class.
Most Web sites today use dynamic Web pages, which present information depending on user preferences. This approach requires a template page, such as an ASPX page, to be used by Web applications. When a Web page is presented to a user, the data retrieved from a data store is dynamically merged into the template and displayed to the user. Although this approach allows the same page to be tailored dynamically to incorporate user preferences, it has certain problems. These dynamic Web pages are less scalable.
Storing frequently requested data in memory variables on the server side is a familiar concept for ASP developers. In classic ASP, two intrinsic objects, the Session object and the Application object, are used to store application data in memory variables. The Session and Application objects are available in ASP.NET, but their functionality is not enhanced much. ASP.NET encapsulates the application data caching in the Cache class.
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