Caching is a great way to cut down on processing. A client can say, “Hey, I have this version of an object, is that the same one you have?” And the server can either say, “Yep, they match” or “No, here, have the latest and greatest version.”  Ok, that’s a simplified version but the reality is just as good. Take an HTML web page that has several JavaScript files and CSS files and a couple of images, not to mention the HTML that makes up the page. That could easily add up to over a MB.  The table below is the base files and that’s not counting any of the image files or nested files the CSS may come up with.

Well, actually, the client passes in the “If-None-Match” header with an ETag and the server compares that ETag with the one it has for the local version and can respond with an HTTPStatusCode of NotModified (304) or with a full blown version of the object. Not only that, a number of the CSS and JavaScript files may be reused on multiple pages. And we pay $0.15 / GB, which may not seem like a lot, but let’s take a look at a simple scenario. You have a dynamic html page that uses AJAX and the size of the physical files is 1 MB. In addition, each users generates an additional Megabyte of Ajax created calls. That means that every thousand users/day will cost you $0.30 in bandwidth costs, half in Ajax created calls and half in static files. But it doesn’t have to cost that much. If you can enable caching you can drastically cut down on those costs.

Let’s say, just to begin with, that you can deliver all of your static files in a way that each individual user can cache them. That means that the first time each of those thousand users hits your web site, they are going to download the megabyte of static files plus they will generate the megabyte of Ajax calls so your cost / thousand users day one will be $0.30 but the cost on subsequent days will be $0.15. Over the course of a month that changes things from $9.00 ($0.15/day in static files + $0.15/day in Ajax calls over 30 days) to $4.65 (one time cost of $0.15 in static files and the $0.15day in Ajax calls over 30 days).

But wait, it gets better. Because there exist a number of intermediary cache servers between your clients and your server that pass information between your clients’ PCs and your server. If you happen to be able to specify the Cache Control headers to set it to be Public then all of those servers between your clients and your server are allowed to cache it. Which means the following is a very plausible scenario:

• User A opens your URI in the browser
• The HTTP request is routed through cache server XYZ which checks to see if it has a copy of the html. It doesn’t so it passes the request along.
• Your server gets the request and returns the HTML with an ETag and Cache-Control: public and an Expires of one hour from now
• Server XYZ keeps a copy of the HTML, ETag and Caching information and passes it back to User A.
• User A’s browser interprets the markup and ends up requesting more information from your server, passing through cache server XYZ and the process is repeated.
• User A now makes an AJAX request which is not cacheable.
• The HTTP request is routed through cache server XYZ which checks to see if it has a copy of the request. It doesn’t so it passes the request along.
• Your server gets the request and returns the Ajax information along with Cache-Control: nocache.
• Server XYZ gets the Ajax information, notes the nocache and passes it back to User A without keeping a copy of it.

Now we have a cached version of the HTML (and images and CSS, etc) in sitting in cache server XYZ. This means that:

• User B opens your URI in the browser
• The HTTP request is routed through cache server XYZ which checks to see if it has a copy of the HTML. It does and that HTML hasn’t expired so it returns that HTML to User B.
• This is repeated for all of the content you marked as cacheable.
• User B now makes an Ajax request.
• The HTTP request is routed through cache server XYZ which checks to see if it has a copy of the request. It doesn’t so it passes the request along.
• Your server gets the request and returns the Ajax information along with Cache-Control: nocache.
• Server XYZ gets the Ajax information, notes the nocache and passes it back to User A without keeping a copy of it.

This means your server never sees the request for the HTML from User B so you don’t end up paying bandwidth charges for it. Which means your monthly cost per thousand users will be closer to $4.50 than $4.65. But it also means that your server is free to handle the interesting things (Ajax responses, for example) instead of having to deliver up static content.

This is, of course, an over simplification of the process but one that illustrates the general principle. Unfortunately, it’s not something that’s implemented everywhere. But I’ve just made a modification to AzureCommands to add CheckBlobCache which check to see if an ETag matches in order to enable returning a 304 (Not Modified). I’ll be covering this in far more detail in the upcoming week as I reveal and explain the Azure MOOP Framework.