ASP.NET 2.0: Cache In on Performance Shortcuts

Whether you're an ASP .NET developer who works with data-based applications or a SQL Server DBA supporting ASP.NET applications, you'll find new capabilities in ASP.NET 2.0 to help you boost yourWeb site's performance.With the release of SQL Server 2005,Visual Studio 2005, and Microsoft .NET Framework 2.0, Microsoft continues to enhance its support at every tier of an ASP.NET application.At the client tier, ASP.NET 2.0 introduces callback functions that let you provide a dynamic, interactive application display without increasing roundtrips to the server. On the Web server tier, new page and partial-page caching options improve performance and give you more control over cache settings. And on the database tier, you can now create SQL Server dependencies to automatically invalidate cached data that the Web server is using.

Callback Functions

When a user makes changes within a Web page, the speed of your application's response affects that user's perception of your application's performance. But the amount of data you transmit to support those changes actually affects your application's scalability and performance.

In previous releases of ASP.NET, you enable a Web page's dynamic elements by sending the client a set of Java or JScript functions along with all the data those scripts should act on. For example, if you want to change the content of DropDownListBox B based on the user's selection in Drop-DownListBox A without making a server roundtrip, you send the client all possible options for DropDownListBox B along with the JScript code that will be called whenever a user selects something in Drop-DownListBox A. However, this approach has some significant performance limitations when you have a large list of potential options. You can't provide a truly interactive UI if you must download potentially thousands of bytes that the user might never access.

Instead, your client-side script needs to retrieve additional data into the client's desktop-based browser without needing to refresh the entire Web page.This technique, called Asynchronous JavaScript And XML (AJAX), originated years ago as part of custom enhancements to Microsoft Internet Explorer (IE). Over time, all major browsers implemented in some fashion the XMLHTTP object that Microsoft introduced, and Microsoft is now working on a robust set of AJAX-based tools called Atlas to support high-performance, interactive Web pages. The Web sidebar "Atlas Takes On the World," introduces Atlas, but as powerful as this toolset promises to be, it didn't ship with ASP.NET 2.0— callback functions did.

Callback functions in ASP.NET 2.0 let you request from your server additional data based on a user action. And rather than writing the JScript code to perform this functionality, you can leverage built-in ASP.NET 2.0 code that lets you retrieve data directly from the server without reposting the entire page to the client.

Callback functions use ASP.NET's ICallbackEventHandler interface. This interface defines two server-side methods that your ASP .NET page needs to implement to handle calls from a Web client back to your server page. Your page calls the first method, RaiseCallbackEvent(ByVal eventArgument As String), when the client's browser raises a callback event to your server.The code you use to call Raise-CallbackEvent must use the RaiseCallback-Event method name because ASP.NET looks only for a method with this name. In addition, the ASP.NET-generated code accepts a single string as the input parameter to this method, which then passes the string to the XMLHttpRequest object for processing. This method doesn't return anything—meaning that in C#, it's a void method, and in Visual Basic (VB), it's a Sub method.

YourWeb page then needs to implement the GetCallbackResult method, which the page calls to retrieve the result of the Raise-CallbackEvent method.This second method doesn't accept an input parameter, but it returns a string value, so you need some client code to parse and react to the returned string. For more complex operations—for example, those that populate a DataGrid—you want the returned string to contain XML that you can parse into the rows and columns of your grid.

You might think you need to add JScript functions to your page to implement these server-side methods for ASP.NET callback functions. But your page needs to perform only four steps to make a callback to the server and retrieve the results—and ASP.NET generates code for the first three steps for you.The four steps are

Let's look first at Step 4, which you need to have in place to generate the code for steps 1-3. In your Web page, you need a function that accepts two parameters: the result and a context (i.e., the name of the client script making the callback). For this example, let's call this function ProcessCallbackResult.The result parameter will contain the string returned from the callback.

Next, to generate the code for steps 1-3, you need to define as part of your page's loadevent-code the key end points for the callback processing. Step 1 is to get, at runtime, the address of your RaiseCallbackEvent method in your server page and pass it to the client page.This processing starts with a call to the shared (or static) methodPage.ClientScript .GetCallbackEventReference(). This overloaded method accepts the name of the ProcessCallbackResult function on the client along with three to five additional parameters that define your callback function.

The call to Page.ClientScript. GetCallbackEventReference() is important because you pass it the name of the client function you want called, and it returns a string that makes the callback, gets the callback result, then passes that result to your function.This code generation works because the two methods you define to implement the ICallbackEventHandler in your server code are limited by name and parameter types, letting .NET generate the necessary client code to call these server-side methods. I encourage you to review this functionality in more detail on the Microsoft Developer Network (MSDN) to see how to define error handlers on your client and other robust capabilities that are beyond the scope of this article. A good starting point—beyond the GetCallbackEventReference() method's Help page—is the MSDN article "Implementing Client CallbacksWithout Postbacks in ASP.NET Web Pages."

After you call GetCallbackEventReference(), you combine the result of the call with a simple client-side script to wrap the generated function logic with a name that you can recognize and reference.You create the function by combining the string result from the GetCallbackEventReference() call with a JScript function header. For example, if you assigned the result of the GetCallbackEventReference() call to a local variable called stringDelegate, your clientFunction string could be generated as

clientFunction = "function   GetData(strParam, context)    { " + stringDelegate + "; }"

This code defines a complete client-side JScript function, GetData, which implements the full callback interface defined on the server, then passes the results to Process-CallbackResult, which you defined earlier. To call this new client function, you must simply include it in your Web page by calling the Page.ClientScript.Register-ClientScriptBlock() method.

The last step is to reference the GetData client function. For example, in an onchange() event for a client control, you can call the GetData function, passing it two parameters: strParam and context.The result of that call will call your custom Process-CallBackResult function, which will implement code to parse the returned string and update the controls on the page. Because of space constraints, I don't include an example of this logic. But in the QuickStart guides on the ASP.NET and MSDN Web sites, you can find valuable examples of implementing callback functions.

All this processing will occur without the user seeing a complete refresh of the page and without the server needing to retransmit the entire page.Callback functions also provide performance advantages compared to using only cached page data. For example, with a callback function, you can take an otherwise cached page and, as the page loads into a user's browser, call back to your server and retrieve real-time data without needing to recompile or change any of your cached data.

Output Page Caching

Output page caching, introduced in ASP.NET 1.0, lets you specify that the dynamic content generated as a response for a given page request be kept in memory for future requests for the same page.You can keep this data in memory for a limited number of requests or for a limited amount of time. And if any parameters change the data that's requested, the cache will store different copies of the data based on those parameters.

Output page caching is a powerful scalability and performance tool but can raise concerns about data freshness.Although you can let some data get reasonably stale, in most cases, applications expect up-to-date information. New ASP.NET 2.0 features at the database tier can help resolve concerns about stale data. But note that even if you set your cache to only a 1-second duration, you'll still see a significant increase in a busy site's scalability and performance.

ASP.NET 2.0 introduces master pages, which provide a single source file that acts as a template for common data within your display.This feature requires a way to let this common data be cached for all pages that reference the master page without requiring that the content inside of each page also be cached. For example, if the caching declaration was controlled by the master page, which is used across multiple pages on your site, all your pages could potentially contain the same data. I mention this to stress that output caching doesn't need to occur solely at the page level. You can also implement output caching for user controls. The only difference for user controls is that the declaration is located in the user control file instead of theWeb form. Note that for output caching, the duration is measured in seconds (not milliseconds, as you'll see in the discussion of SQL-based caching). With that in mind,output caching in ASP.NET 2.0 uses the same declaration style you're familiar with:

<%@ OutputCache Duration="120"   VaryByParam="none" %>

The most important enhancement that ASP.NET 2.0 brings to output page caching is that you can customize your cache, thanks to two new capabilities for better managing the details of your server's cache. ASP.NET 2.0 lets you customize some cache settings by using the web.config and system.config files on your server. By using these files, you can predefine cache sizes, set whether certain features are disabled, and so on. For example, if you're a hosting provider and want to limit the resources that individual sites use on your hosting server, you can modify the machine.config file and set limitations across the hosted sites.

As part of the cache-configuration process, you can leverage a second new capability in ASP.NET 2.0: cache profiles. The idea behind a cache profile is that you probably have many different pages or parts of pages that you want cached using the same settings. Rather than spreading these settings across different locations in your application, you can name a set of cacheconfiguration settings inside the cache settings in your configuration file.You can then reference this group of settings by name and modify them in one location.

For example, if you declared a profile for a 60-second cache in a web.config file called "CacheFor60," your web.config file would contain the profile that Listing 1 shows.The Output Cache declaration in your page might look like the following statement:

<%@ OutputCache    CacheProfile="CacheFor60"    VaryByParam="prodgroup" %>

This code leverages the profile, then has the cache vary by the parameter "prodgroup." For more information about these cacheconfiguration settings, see the Microsoft article "Cache Configuration in ASP.NET."

The Cache Object

I've focused mainly on page-oriented caching so far, but now it's time to look at your data. It's common for everyone accessing a Web application to be referencing the same set of products, courses, or other set of key data elements that are common across users. By using the Cache object, a shared (or static) class that's available to your ASP.NET application, you can declare an entry in the data referenced by the object.Then, similar to session data, the data will be available on your next call.

However, unlike session data, which is user-specific, data in the Cache object is available on the next call to your application by any user of your application. Thus, the Cache object isn't a good place to put userspecific information. Still, it's an excellent place to hold data that you'll use across all users of your application.

The Cache object isn't new with ASP.NET 2.0, so I don't want to spend too much time on it. But I do want to mention one change that resolves a glaring hole in the original .NET Framework 1.* implementations. As part of a Cache entry, you can define a dependency on an XML or other system file,but you can't declare a dependency on a database. ASP.NET 2.0 extends the Cache object so that you can now create a custom class that inherits from System .Web.Caching.CacheDependency to define logic for a custom dependency. Although you can use this capability to define a custom dependency on your database,ASP.NET 2.0 also provides an updated implementation that handles database dependencies for you, as you'll see next.

Data-Dependency Refresh

A new ASP.NET 2.0 caching feature is the ability to create a cache dependency based on SQL Server.You can base the dependency on both time and table updates. If you want a page generally to be cached for 5 minutes but want it to refresh sooner if key data changes, you would use the SQL Cache dependency.ASP.NET supports two modes for this caching model: one that is backwardcompatible to SQL Server 2000 (and, by default, 7.0) and one specific to SQL Server 2005. Let's look first at the SQL Server 2000-compatible model, called the polling method.

With the polling method, you configure ASP.NET to automatically poll the database on a specified interval and refresh the cache if any changes occur to the table you're interested in.This model lets you provide a nominal refresh time for your Web page but still react to key changes in your database more frequently. The disadvantage is that this method is still a time-based refresh. And configuring this type of database dependency requires more effort than leveraging SQL Server 2005's automated change notifications.

However, even if you've already created a custom database polling solution, you still might be interested in using this model to leverage Microsoft's coding and reduce the amount of custom code in your application. More important, your custom solution might invalidate the full cache to check whether the data has changed, whereas the SQL Cache dependency model checks the database for changes without invalidating the cache unless there's new data to include.And, you can associate SQLCacheDependency as a property on the DataSource object you're using in your ASP.NET page instead of writing any actual code—but more about this after we walk through the configuration.

To configure this model, you need to use the aspnet_regsql.exe utility, which lets you configure your database to support this polling-based solution. Aspnet_regsql.exe is a command-line tool, which requires you to define a string of command-line parameters. The first set of parameters defines the database-connection string for the database on which you want to create the automated SQL dependency.

You use either three or four parameters to build the connection string. The first parameter, —S followed by the name of your server, defines the server. If you're referencing a named instance, include the instance name as part of this parameter.The second parameter, —D followed by the name of the database, is the database you'll reference on that server. Finally, you need to specify credentials. If the database is in your current domain or on your current machine, you can use —E, which tells aspnet_regsql.exe to use integrated security and your current account to reference the database. Alternatively, you can supply a username and password, preceded by the —U and —P parameter labels, respectively.

The example command in Listing 2 defines the database by using the above connection parameters and some additional parameters to create the database dependency. For a database dependency to work, you need to define two additional items beyond the connection string. The first is an ASP .NET-specific table that your database updates when a table of interest is updated.The database needs only one common table to record possible updates to any of the application tables.The —ED (think "Enable Database") parameter in Listing 2 tells aspnet_regsql.exe to create this table, called AspNet_SqlCache-TablesForChangeNotification, and the five stored procedures (prefaced in the AspNet_ namespace) that ASP.NET uses to access it.

The second item you must define is which table should be tracked for updates. The —ET parameter tells aspnet_regsql.exe that you want to "Enable a Table" for a SQL Cache dependency.The next step is to name the table on which this trigger will be created to register updates into the database's changetracking table. The —T parameter in Listing 2's example tells aspnet_regsql.exe which table's definition to modify, and the utility will then add a trigger called