11 July 2011

Caching in IIS, TMG and the browser - How it all fits together Part III - IIS cache

In the previous two parts of this article

Caching in IIS, TMG and the browser - How it all fits together Part I - Browser cache

We explored how the items being served from a web server gets stored and retrieved further down the line.  Other than defining what items are allowed to be cached and which items are not, IIS also performs its own output caching.

Configuring Output Caching in IIS

There are many resources explaining how to configure caching in IIS.  I will focus just on the very basics and how it interacts or interferes with the the other caches.

There are a few basic concepts you need to be aware of for the next section to make sense.

  • Output Caching settings
  • Feature Settings
  • Enable User made Cache
  • Enable Kernel cache
  • Maximum cached response size
  • Cache Size Limit
  • Cache Rules
For the detailed information on these check http://technet.microsoft.com/en-us/library/cc732475(WS.10).aspx

The resultant cache configuration will be visible if you examine the HTTP header information on your test machine.


In essence, if caching is setup correctly at the web server level all other caches should "fall in line" by perpetuating the cache setting you specify at the web server.  If however the cache configuration on the web server is bad - you will propagate those wrong settings all the way down to the browser cache.

Configure a test machine
By design, a machine will use all the caches in sequence, and hide the details from you.  To troubleshoot the IIS cache you need to setup a test machine to eliminate all other caches.  

Proxies
This entails having to bypass using either a forward or reverse proxy cache by checking your browser connection settings.  Te ensure a forward cache is avoided set your browse to use "no proxy."    To test your application connect to the host server's name directly and not through a reverse proxies name or IP.  If you are connecting to an NLB web application try hit only one of the servers by using a unique non NLB IP.

Disable Browser cache
Firefox and Firebug has a very useful feature for this.  It allows you to totally disable the browser cache.  From the Net tab check the "Disable Browse Cache."  All requests to the same content should now generate a 200 response code, because all items are being retrieved remotely.   



This should now have set up a reliable machine to test your IIS cache.

Checking on caching performance

As with Browser and Proxy cache, the caching is something that is transparent by design, as in there is no way for you to know where the data is coming from unless you are looking at the correct layer.

For IIS you use Performance Monitor.  Add the Web Service Cache counters

There are various section of counters, that give you information from the different cache components. 

Probably most important is the section in orange here.  The "Current" counters give you information about the existing state
  • File Cache Memory Usage
  • Files Cached
  • Metadata cached
  • URIs Cached
The cache is generally dynamic and as such these numbers should change.

By generating repeat requests from your test machine you should see the files being loaded into cache and then getting cache hits thereafter.  Once the TTL for the cache file expires it should automatically be flushed.

This is going to be specific to the output cache sestting for that site / application, So you need to know what you want to test for.  (In my test example I want to ensure the .jpg files are not cached at all)


Clearing the cache manually
If items were incorrectly marked for caching they could be stuck in the server output cache for a long, long time.  You would then want to clear the cache so that all browser and proxy connection can determine that the item had changed and therefor flush the down level caches.

Before starting to flush the cache  have a look at the current counters.


To totally clear to cache do the following:

From the IIS management console
  • Disable output caching at the IIS server level.
  • Restart IIS
  • Re-enable output caching
  • Restart IIS
Once this is done you check the "current counters" again.  All the current values should be 0.  Your cache items should come in when being called for and should get flushed as the desired TTL is reached.  Use your test machine to verify this behavior.


Conclusion
Caching is a great way to improve web performance and it does this by take load of the client machines the common networks and the web servers.  If however you get something stuck in cache it could be difficult to find out where it is getting stuck and then to flush it.

Default caching setting on browse and TMG and even IIS may not leverage every single grain of performance gain, but they do "line up" nicely.  Uninformed fiddling with these, could introduce cache related issues without realizing any significant gain.






No comments:

Post a Comment