C# ПІДРУЧНИКИ / c# / Hungry Minds - ASP.NET Bible VB.NET & C#

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.

It is important to clarify that 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. These classes are covered later in the chapter. Some of the classes used by ASP.NET for managing cache behavior are discussed next.

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 included 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. For example, consider that a Web server receives the following requests:

http://localhost/caching/displaysuppliers.aspx?city=london

http://localhost/caching/displaysuppliers.aspx?city=NY

http://localhost/caching/displaysuppliers.aspx?city=london

http://localhost/caching/displaysuppliers.aspx?city=SJ

If multiple requests for the Displaysuppliers.aspx page with the city parameter, "london," are to be cached, the @OutputCache directive must set the VaryByParam to city, as follows:

<% @OutputCache duration = "60" varybyparam = "city"%>

This statement will cause ASP.NET to cache the requests for the Displaysuppliers.aspx page and maintain the cache citywide. Then, the cache will contain three versions (one each for London, New York, and San Jose) of the Displaysuppliers.aspx page.

HttpCacheVaryByHeaders

The HttpCacheVaryByHeaders class is used to cache multiple versions of an ASP.NET page, depending on a particular HTTP header. Therefore, the cache will have multiple versions of the ASP.NET Web page — one for each value of the specified HTTP header. A common use for this class is when you need to generate browser-specific versions of a Web page and store that page in the cache. In such a situation, all future requests for the page from a specific section of browsers are fulfilled from the cache and do not require re-rendering of the page.

If the HTTP header has a value "User-Agent" specifying the name of the browser that requested an ASP.NET page, and if the page is browser-specific, you can set the VaryByHeaders property to "User-Agent". This makes ASP.NET maintain a browserspecific cache. To achieve this, set the @OutputCache directive as follows:

<%@OutputCache Duration = "120" VaryByHeaders = "User-Agent">

If the ASP.NET page is requested multiple times by the same browser, the first request will cause the ASP.NET page to be rendered and stored in the cache. The subsequent requests will then be fulfilled from the cache. However, if a different browser requests the same page, ASP.NET will re-render the page and store this version also in the cache. This way, the cache will have two versions of the same page.

Cache API Performance Monitor counters

The Performance Monitor counters can be used to determine the efficiency and performance of ASP.NET applications. To monitor the cache-specific counters in Performance Monitor, complete the following steps:

1.Select Start → Programs → Administrative Tools → Performance to start the Performance Monitor.

2.In the Performance Monitor window, use the Add counter toolbar icon to view the list of ASP.NET cache counters.

3.In the Add Counters dialog box, from the Performance Object dropdown list box, select ASP.NET Applications. Now, the various cacherelated count ers are displayed in the Counters list box. Figure 17-4 shows the Add Counters dialog box.

Figure 17-4: The Add Counters dialog box

Some of the cache counters are described as follows.

§Cache Total Entries: Represents the total number of items stored in the ASP.NET cache.

§Cache Total Hits: Represents the total number of items that were requested by a user and were successfully retrieved from the cache and returned to the user. This counter presents an overall picture of the "success" of the ASP.NET caching engine.

§Cache Total Misses: Represents the total number of items that were requested by users and were not retrieved from the cache (failed cache retrievals).

§Cache Total Hit Ratio: Represents the ratio of total cache hits to total cache misses for the cache. This counter gives a good overall picture of what percentage of items is retrieved from the cache.

§Cache Total Turnover Rate: Represents the number of additions and removals to the total cache per second. If there are excessive additions and removals happening from the cache, it is an area of concern, because the CPU is potentially spending a lot of time maintaining the cache. This counter is useful in determining how effectively the cache is being used. Large values for this counter indicate inefficient use of the cache.

§Cache API Entries: Represents the total number of entries made explicity in the cache by an application by using the Cache API.

§Cache API Hits: Represents the total number of items successfully found in the cache when accessed only through the external Cache API.

§Cache API Misses: Represents the total number of fetch requests made to the cache that failed. This counter is applicable only to fetch requests that are made explicitly by using the external Cache API.

§Cache API Hit Ratio: Represents the cache hit-to-miss ratio when accessed through the Cache API.

§Cache API Turnover Rate: Represents the number of additions and removals to the cache per second when used via the external Cache API, excluding the internal Cache APIs used by the ASP.NET Framework.

After understanding the Cache API and Cache Performance Monitor counters, let us now discuss page output and page data caching.

Caching Page Output

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. Because the pages are generated each time a request is made, as shown in Figure 17- 5, dynamic Web pages require more server resources. Having a background batch process that pregenerates the HTML output is one of the ways in which this problem can be circumvented. However, this approach fails when the number of user requests is unknown or the number of requests is very large. In such a case, what is needed is a smart caching solution. ASP.NET provides the output cache feature to solve this problem of scalability.

Figure 17-5: Processing a Web page in classic ASP

Page output caching allows the entire content of a given page to be stored in the cache. Thus, unlike dynamic Web pages, the cached ASP.NET pages are served statically directly from the cache, instead of dynamically executing them from a Web server for

End Sub

</script>

<body>

<h3>Output Cache</h3>

<p>This page was generated at:

<asp:Label ID=lblServerTime runat="Server"/>

</body>

</html>

Figure 17-7 shows the output of this code.

Figure 17-7: A sample output

To test the preceding code, switch to IIS and locate the file that you created. Next, right - click the file and choose Browse from the context menu. Repeat these steps after a few seconds, and take note of the time displayed. In this Web page, if the @OutputCache directive were not used, the page would have displayed the exact server time on receiving a client request. However, because the @OutputCache directive is set to cache the output data for 300 seconds, the server time displayed will be same for five minutes — all requests received within five minutes of the first request will display the same time. After five minutes, when the cache is expired, the first request received will cause the server to execute the ASP.NET page once again and cache the output data. It is also possible to specify an absolute expiration time. To do so, you need to call the Response.Cache.SetExpires method and pass the absolute time as an argument. For example, to specify the absolute expiration time for an ASP.NET page at 9:00 a.m., use the following VB code:

Response.Cache.SetExpires ( DateTime.Parse ("9:00:00 AM"))

Tip Absolute expiration is very useful for pages that do not change frequently.

As mentioned earlier, the entire HTML output is cached by default when the @OutputCache directive is specified. However, if you do not want this default behavior of caching, you can apply region caching. Region caching, also called fragment caching, allows specific sections of the output page to be cached instead of the entire page. If an ASPX file consists of different code sections, you can set different cache settings for these different code sections. For example, if a Web page reads several database tables, processes some XML-formatted data, and also displays some customized content for a user, then the page can be cached in sections. The database table read sections can be cached for one hour, the XML portion can be cached for 10 minutes, and the user-specific data might not be cached at all.

This type of fragment caching is achieved by using user controls and setting the @OutputCache directives in the user control page. When the user control is instantiated in a container page, the cache settings of the control are applied along with any cache settings on the container page. Figure 17-8 shows the fragment caching.

Figure 17-8: Fragment caching

If you set the cache time of a page to 60 seconds and that of a contained user control to 300 seconds, the cached output will expire and the content of the page will be refreshed after every 60 seconds. However, the contained user control will be refreshed independent of the container page.

Caching Page Data

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. The following sections cover the Session and Cache objects in detail.

Session object

The Session object is used to store data across multiple requests for each user. When a session begins, a unique key is assigned to the user. ASP maintains the session state for each user by providing the client with this unique key. This key is stored in an HTTP cookie that the client sends to the server on each request. The server can then read the key from the cookie and rebuild the server session state. But some limitations exist to using the ASP Session object over the ASP.NET Session object:

§Process dependency: In the case of classical ASP, the ASP Session object is process-dependent. If an ASP service on a Web server is restarted, the session state of all the users on that server is lost, and all these users are assigned new sessions. On the other hand, the ASP.NET Session object can be stored in the same memory that

ASP.NET uses (in-process), in separat e memory from ASP.NET (out-of- process using Windows NT Service), or in a persistent storage (in SQL Server). Since the ASP.NET Session object can be stored out-of- process, it is process-independent. ASP.NET session state can run in a separate process from the ASP.NET host process. Therefore, the session state is available irrespective of the ASP.NET process. Of course, you can still use session state in a process similar to the classic ASP.

§Server farm support: In a real-world scenario, as the load on a Web server increases, the Web administrator balances the load across multiple Web servers by replicating the Web site on multiple servers. The load balancing can be achieved by using additional hardware, such as Cisco LocalDirector, or software solutions, such as Windows Load Balancing Services. In the classic ASP scenario, there is no guarantee that all requests from a user will always be sent to the same Web server. In such a case, the different Web servers will treat the incoming requests from the user as separate sessions. As the user moves from one Web server to another, the session state is not carried along with the user. Until the user returns to the same server, the session state cannot be accessed. This problem can be solved by using network IP–level routing solutions, which can ensure that the client IPs are routed to the originating server. However, some Internet service providers (ISPs) choose to use a proxy load-balancing solution for their clients. On the other hand, ASP.NET supports server farm configurations. The new out- of-process model allows all servers in the farm to share a session state process. You can implement this by changing the ASP.NET configuration to point to a common server. Now, the session state can be stored out of process as well as out of system by using the session state service. The session state can be recorded into a SQL Server database, which can be on a cluster for the purpose of reliability.

§Cookie-dependent: ASP sessions are cookie-dependent. As already mentioned, ASP sessions are identified with a unique Session ID cookie that is sent by a Web server to a Web browser when the session is established. The browser sends the cookie with every request made to the Web server. Clients that don't accept HTTP cookies can't take advantage of session state. Some clients believe that cookies compromise security and/or privacy and thus disable them, which in turn disables the session state on the server. ASP.NET sessions, on the other hand, can be configured to be cookie-independent. ASP.NET reduces the complexities of cookieless session state to a simple configuration setting.

State management in classic ASP

In classic ASP, when a client requests ASP scripts from a Web server, a session is established between the client and the server. During this session establishment, the Web server generates a Session ID cookie and sends it to the client. The Session ID cookie is sent to the client in HTTP header. Therefore, to identify its session data in subsequent requests, the client shares a common key (Session ID cookie) with the Web server. This state management model works well for the clients that accept HTTP cookies. However, there are certain clients who think that cookies compromise on security. This is because the Session ID cookie is the only way a browser request is identified. Any other HTTP request with a matching cookie is assumed to have come from the same browser. Thus, a hacker who succeeds in hijacking the cookie could use a user's active session. Due to these security threats, some clients disable cookies and thus disable session state on the server. Thus, the ASP scripts do not work well for the clients who do not accept HTTP cookies.

Cache object

ASP.NET provides a full-featured cache engine that can be utilized by pages to store and retrieve arbitrary objects across HTTP requests. This is a replacement to the Session and Application variables that were used in classic ASP. The ASP.NET cache is private to each application and stores objects in memory. The lifetime of the cache is equivalent to the lifetime of the application. Therefore, when the application is restarted, the cache is also re-created.

ASP.NET encapsulates the application data caching in the Cache class. The Cache class is always associated with an ASP.NET application. When an ASP.NET application starts, an instance of the Cache class is always created. The Cache object is destroyed as soon as the ASP.NET application stops. Therefore, the lifetime of this Cache object is the same as the lifetime of an ASP.NET application.

The ASP.NET cache provides a simple dictionary interface that enables programmers to easily place objects in the cache and later retrieve them from it. In the simplest case, placing an item in the cache is just like adding an item to a Session or Application object. For example, you can add a variable to the Cache object as follows:

Cache("myvar") = 20

Each cache item has a key/value pair. In this code, "myvar" is the key and 20 is the value. In addition to storing key/value pairs, the Cache object provides additional functionality to store transient data. To achieve transient data caching, you can use dependencies, which enable you to invalidate a particular item within the Cache object depending on the changes to the dependent keys, files, or time. For example, an item should be removed from the cache when a dependent file changes. The .NET Framework provides the CacheDependency class that encapsulates the implementation of cache dependencies. The different dependencies are described in the remaining sections.

File-based dependency

File-based dependency invalidates a particular Cache item when a file(s) on the disk changes. For example, consider the following code wherein the product data is loaded from an XML file:

Dim dom As XmlDocument()

dom.Load(Server.MapPath("product.xml")

Cache("ProductData") = dom

You can add a cache dependency to force ASP.NET to expire the "ProductData" item from the cache when the Product.xml file changes. To do so, you need to create an object of the CacheDependency class. If the Product.xml file resides in the same directory as the requesting application, write the following code:

Dim dependency as new CacheDependency(Server.MapPath("product.xml"))

Cache.Insert("ProductData", dom, dependency)

In this code:

§dependency is an instance of a CacheDependency class

§The Insert() method of the Cache class is used to create the ProductData key that is dependent upon the file from which it retrieves data

You can also create a cache dependency based on multiple files. In such a case, the dependency should be built from an array of files or directories. As an example, consider a case in which an XML document arrives in a directory, immediately after which an item in the ASP.NET cache needs to be expired. In such a case, you need to add a cache dependency to the directory.

The following is the complete code of the Web page to demonstrate the implementation of the CacheDependency class:

<%@ Import Namespace="System.IO" %>

<%@ Import Namespace="System.Data" %>

<Html>

<Script language="VB" runat="server">

Sub Page_Load(ByVal sender As System.Object, ByVal e

As System.EventArgs) Handles MyBase.Load

If Not IsPostBack

GetData()

End If

End Sub

Sub GetData()

Dim Source As DataView

Source = Cache("ProductCatalog")

If Source Is Nothing

Dim ds As DataSet

Dim fs As FileStream

Dim reader As StreamReader

'Read the data from the Product.XML file

ds = New DataSet()

fs = New FileStream(Server.MapPath("product.xml"),

FileMode.Open,FileAccess.Read)

reader = New StreamReader(fs)

ds.ReadXml(reader)

fs.Close()

Source = New DataView(ds.Tables(0))

'Cache it for future use and also add product.xml as

a dependency

'Any changes to product.xml will cause us to refresh

the cache (build the cache once again)