MSDN Magazine - April 2008 - (Page 67)

strategies would apply to scaling virtually any application using any technology. Now let’s look at some ASP.NETspecific techniques. Looking at the performance equation, you can see payload plays a significant role, especially when you’re dealing with lim ited bandwidth. Reducing the size of your payload will improve your response time, you’ll gain some scaling benefits from mov ing fewer bytes around, and you could even save some money on your bandwidth costs. One of the simplest things you can do to decrease the size of your payload is to turn on compression. In IIS 6.0, you can specify whether to compress static files, dynamically generated responses (ASP.NET pages, for example), or both (see Figure 4). IIS 6.0 compresses static files on demand, storing them in a com pressed files cache that you specify. For dynamically generated re sponses, no copy is stored; they’re compressed every time. IIS 7.0 is smarter about what it compresses, only compressing files that are used frequently. Compression costs processor cycles, but you typically have plenty of extra processor capacity on a dedicated Web server. IIS 7.0 is fur ther optimized, however, so that when the processor gets really busy, it will suspend compression efforts. There are also dedicated devices for doing compression independent of the Web server itself. Another area ripe for payload reduction is ViewState. During development, it’s quite easy for ViewState usage to get out of hand. Most Web controls use some ViewState, and on controlintensive pages, ViewState can grow to thousands of bytes. To reduce ViewState usage, turn it off on controls where it isn’t needed. In some cases, developers will even eliminate controls to reduce the ViewState. But that’s not always necessary. Most modern Web controls are sensitive to the problem of excessive ViewState and thus provide granular control over its size. There are also hardware devices that can remove and replace ViewState for you without altering your code or how your application runs. One of the most effective technologies for reducing payload size is AJAX. Except that AJAX doesn’t really reduce payload size—it simply reduces the perceived size of the payload while increasing the total number of bytes sent to the browser. Using AJAX, the parent page is smaller, so initial render times are faster. Individual elements in that page then make their own requests to the server to populate data. Effectively, AJAX spreads the payload out over time, giving the user something to look at while other bits load. So using AJAX will improve your user experience overall, but refer back to the perfor mance equation to measure the real costs of your effort. AJAX typi cally increases compute time on the client, sometimes dramatically, to the point that performance can be unacceptable. If the AJAX roundtrips to the server to populate individual ele ments are replacing entire page requests, you’ll have a net decrease in roundtrips. But in many cases, you’ll find the total number of roundtrips for a given user will increase. You just need to be dili gent about your testing so you know whether AJAX has improved performance or reduced it. Caching Minimizing Payload Experts in scaling ASP.NET applications talk a great deal about caching. Fundamentally, caching is about moving data closer to the user. In a typical ASP.NET application, before any significant optimization work has been done, virtually all the data the user needs is in the database and retrieved from the database with ev ery request. Caching changes that behavior. ASP.NET actually sup ports three forms of caching: page caching (also known as output caching), partialpage caching, and programmatic (also known as data) caching. Page caching is by far the simplest form of caching. To use it, you add an @OutputCache directive to your ASP.NET page and include a rule for when to expire it. For example, you could specify that the page should be cached for 60 seconds. With that directive in place, the first request of that page will process normally, access ing the database and whatever other resources are needed to gen erate the page. After that, the page is held in memory on the Web server for 60 seconds and all requests during that time are served directly from memory. Unfortunately, while this example is straightforward, it ignores a fundamental reality of page caching: virtually no ASP.NET page is so static that you can cache the entire thing for any length of time. That’s where partialpage caching comes in. With partial page caching, you’re able to mark portions of an ASP.NET page as cachable so that only the parts of the page that do change regularly are computed. It’s more complicated but effective. Arguably, the most powerful (and most complex) form of cach ing is programmatic caching, which focuses on the objects used by the page. The most common use of programmatic caching is to store data retrieved from the database. The most obvious problem with caching data is that the underly ing data may have changed since you cached it. Expiration of cach ing is the biggest challenge you’ll face in implementing caching of any form. But there’s also memory to consider. On a busy ASP.NET server, memory becomes a significant issue Figure 4 Configuring Compression Server-Wide in IIS 6.0 ASP.NET Performance april2008 67

Table of Contents Feed for the Digital Edition of MSDN Magazine - April 2008

MSDN Magazine - April 2008 Contents Toolbox CLR Inside Out Basic Instincts Cutting Edge Foundations Test Run Service Station Windows with C++ Going Places { End Bracket }

MSDN Magazine - April 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.