Real World Computing
.NET performance
One way you as a web developer can make use of the ASP.NET cache is to include a reference to System.Web.DLL in your application project, then access the Http.Runtime.Cache property. You can also affect caching, both at web server and within the proxy server, by making some tiny changes to the pages whose content you wish to cache. You can do this by adding the following line to the top of each page:
<%@ Page OutputCache VaryByParams="none" Duration="30" %>
This statement pins the results of the page into ASP.NET's page output cache, thus avoiding regenerating the page for 30 seconds. You can, of course, vary the Duration parameter for longer (or shorter) times, as appropriate. This trick works well if the page generated takes no input parameters, but pages that produce their output based on input parameters can also be cached. The VaryByParams section enables you to direct ASP.NET to create caches for various values of any given input parameter, which lets you cache dynamic output for certain cases where the output isn't varying very fast. For example, suppose you had a reporting application that creates updated reports once per night and allowed your users to view specific reports by specifying a 'reportid' input parameter that indicates which report to return. The user would request a report via a URL such as 'http://reportsrv/rptapp.aspx?ReportID=1' to obtain the first report, 'http://reportsrv/rptapp.aspx?ReportID=2' to obtain the second and so on. In this case, you'd use the VaryByParams parameter in the Page directive as follows:
<%@ Page OutputCache VaryByParams="ReportId" Duration="7200" %>
This statement would cause ASP.NET to create separate cache entries for each requested report, with the cache contents being maintained for 7,200 seconds (two hours). The beauty of this is that not only does caching occur on the web server, but ASP.NET tags the HTTP response headers to indicate that this content can be cached by local proxy servers too.
This approach can improve performance significantly by avoiding extra work in recreating reports that haven't changed, but if your users are getting content from cache there are a couple of potential problems to consider. For pages with advertising content, or wherever you need accurate hit counts, this approach may not be ideal, since you risk under-counting your hits (hits from cache wouldn't be counted). There's also a risk that users may get out-of-date information, so you need to tune that duration parameter very carefully with respect to the freshness of the underlying content: reports that change once per day can safely be cached for several hours, whereas current seat reservations for an airline change so fast that caching is probably not viable at all.
.NET Performance Counters
With the .NET Framework, Microsoft introduced several new performance objects, which are organised into three broad classes: CLR internal objects (ten individual objects); .NET Data Providers (one object for SQL, and one for Oracle); and ASP.NET objects. On my own computer, I'm seeing a total of six ASP.NET objects, of which two are .NET 1.1 specific and two are .NET 2 specific. These new objects provide you with a huge amount of information, much of which, however, is likely to be at very low level and hence most useful to the ASP.NET design team themselves, or perhaps to the designers of your application. But there are a couple of objects that can provide you with information on application-level performance that might help you in performance tuning:
