MSDN Magazine - April 2008 - (Page 68)

for a variety of reasons. Whenever an ASP.NET page is computed, it uses some memory. And the Microsoft® .NET Framework is set up to allocate memory very quickly but release it relatively slowly, through garbage collection. The discussion around garbage col lection and .NET memory allocation is an article unto itself, one that has been written a number of times. But suffice it to say that on a busy Web server, the 2GB memory space available for your ASP.NET application is in high demand. Ideally, most There is now a patch of that memory usage is for ASP.NET that will temporary, as it is allocat automatically remove ed for variables and struc tures used in computing a objects from the Web page. programmatic cache if you When it comes to persis get low on memory, which is tent memory objects, how better than crashing. ever, like inprocess session and cache objects, memory usage becomes much more problematic. And of course, these prob lems only surface when your application is really busy. Consider this scenario: your Web site is hopping from some new marketing promotion, there are thousands of users hitting the site, and you’re making loads of money. To maintain good response times, you’re caching portions of pages and groups of data objects wherever possible. Each page request from a user consumes a bit of memory, so the bar of consumed memory keeps sliding upward. The more users, the faster that bar moves. There are also big jumps from the cache and session objects. As the total memory used gets close to 90 percent of ASP.NET’s default cache memory limit, a garbage collection event is called. The garbage collector works its way through the memory space, shuffling down persisted memory objects (like cache objects and session objects) and freeing up memory that’s no longer used (the memory that was used to compute the Web pages). Freeing up un used memory is fast, but the shuffling of persisted objects is slow. So the more persisted objects you have, the harder time the garbage collector has doing its job. This type of problem can be identified in perform.exe by a high number of gen2 collections. Figure 5 Checking, Locking, and Rechecking a Cache Object // check for cached results object cachedResults = ctx.Cache[“PersonList”]; ArrayList results = new ArrayList(); if (cachedResults == null) { // lock this section of the code // while we populate the list lock(lockObject) { // only populate if list was not populated by // another thread while this thread was waiting if (cachedResults == null) { } } } And recall that while garbage collection is going on, no pages can be served by that ASP.NET server; everything is held in a queue, waiting for the garbage collection process to complete. And IIS is watching, too. If it thinks the process is taking too long and might be hung, it will recycle the worker thread. And while this frees up a lot of memory really quickly because all of those persisted memory objects are thrown out, you’ll have some annoyed customers. There is now a patch for ASP.NET that will automatically remove objects from the programmatic cache if you get low on memory, which sounds like a good idea on the surface. It’s better than crash ing. Just remember that every time you remove something from the cache, your code will eventually put it back. The moment you cache something, you run the risk of it being wrong. Take, for example, a widgets database and corresponding order page. In the initial incarnation of the widget page, every ren dering of that page will involve a request from the database for the number of widgets still in inventory. If you analyze those requests, you’ll likely find that 99 percent of the time, you’re retrieving the same number over and over again. So why not cache it? A simple way to cache it would be over time. So you cache the inventory of the widgets for an hour. The drawback to this tech nique is that someone will buy a widget, then go back to the page and see that the inventory is still the same. You’ll get complaints about that. But far more challenging is when someone goes to buy your widget and sees that the inventory is there, when it’s actually sold out. You could build a backorder system, but either way, you’re dealing with a disappointed customer. Perhaps the problem is your expiration scheme: Time isn’t good enough. You could cache the inventory count until someone buys a widget and then expire the cache object. That’s more logical, but what happens if there is more than one ASP.NET server? Depend ing on which server you go to, you’ll get different inventory counts for the widget. Consider that receiving new inventory (which adds to the count) doesn’t even go through your Web application, and you have a whole new way to be wrong. Synchronizing expirations among ASP.NET servers can be done, but you have to be careful. The amount of chatter you can generate among Web servers goes up geometrically as the number of cache objects and Web servers increases. The impact of cache expiration on performance needs to be studied carefully, too. Under high load conditions, expiring a cache object can cause a lot of grief. For example, suppose you have an expensive query that takes 30 seconds to return from the database. You’ve cached that query to save that high expense because under load, that page is requested once every second. The code for handling cache objects is pretty simple. Instead of retrieving the data from the database when needed, the application first checks to see if the cache object is populated. If it is, it uses the data from the cache object. If it is not, it executes the code to retrieve the data from the database and then populates the cache object with that data; code then continues to execute as normal. The problem is that if you’ve got a query that takes 30 seconds and you’re executing the page every second, in the time it takes to populate the cache item, 29 other requests will come in, all of 68 msdnmagazine ASP.NET Performance

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.