Note: As of 11.4, WebAccelerator is now a part of BIG-IP Application Acceleration Manager.

This is article four of ten in a series on DevCentral’s implementation of WebAccelerator. Join Colin Walker and product manager Dawn Parzych as they discuss the ins and outs of WebAccelerator. Colin discusses his take on implementing the technology first hand (with an appearance each from Jason Rahm and Joe Pruitt) while Dawn provides industry insight and commentary on the need for various optimization features.

 

 

Basic optimizations like TCP options and compression are great, but when you’re really looking to get the most out of your application, you want to go beyond the low hanging fruit and dig further. Fortunately WebAccelerator has a number of options that are just that, beyond the basics. One of the more powerful and popular features that fits that bill is Intelligent Browser Referencing (IBR).

To understand IBR, first it’s important to understand the general flow of a client making an HTTP request. Whenever a client makes a request, and a web server responds with the appropriate content, the client’s browser will store as much of that information as possible in the local cache. This prevents the user from needing to request the same content again for a given period of time. Keep in mind, however that the client browser is the one in charge of determining if that “period of time” is up or not, and whether or not it needs to go fetch new content from the server. If there aren’t specific cache control headers set by the server for each item stored in the local cache to tell the browser when it needs to download a new version, it will have to decipher this itself. To determine this it uses what is known as a conditional GET request.

Dawn Says...

 

There are frequently trade offs that are made between content and performance. End users want dynamic, up to the minute updates when accessing a web application and they also want the content to load as quickly as possible. I’ve often heard the argument that an application can’t be cached because it is highly dynamic and content is always changing. While this is true this doesn’t mean that the content can’t be cached by the browser. Take DevCentral as an example – the content here is always being updated new blogs are posted, comments are added to discussions and wikis are updated – this site is highly dynamic but that doesn’t mean caching can’t be used. With object versioning or Intelligent Browser Referencing (IBR) you can get the benefits of caching at the browser while still ensuring that content is not stale. IBR applies a fingerprint or a version number to content when the object is updated on the server the link changes – this looks like a brand new object to the browser so the old cached copy will not be utilized. IBR gives you the best of both worlds fewer requests and the freshest content possible.

Once you’ve received the content from the web server and stored it locally, you don’t have to download that content again for each request. What your browser will do, however, is send a conditional GET request with an “If-Modified-Since” statement to see if it needs to download a new copy of the content. For instance the logo on your bank’s home page generally stays the same. Once you’ve made a request to a page that contains that logo, you won’t have to download it again until that cache time limit runs out. You will, however, be sending a conditional GET request each time you would have downloaded the content, to check to see whether or not you need a newer version if they haven’t specifically set a cache timeout value.

This may not sound like much but take into account that most web pages have 40+ objects, and a common round trip time is 100+ ms. In fact, stats from http archive show trends upwards of 90 requests, and cache lifetime (days) of 0 in 59% of sites. 59%!! That means that, even if you download absolutely no content, if you have to send a conditional GET for even half of those items you’re looking at a two second delay per page load before the page can properly render, even though it’s being served entirely out of the local cache. This is, obviously, not ideal. You can see in the capture below that in this request, every object is retrieved remotely.

wa_ibr_1

Intelligent Browser Referencing is a technology built into WebAccelerator wherein WA is able to more granularly affect the user’s behavior when it comes to caching. What IBR does is set the cache expiration time to 180 days for all objects being sent from the server to the end user. This means that the end user will not check, even with conditional GETs, for new content from the server for 180 days. That will enable it to load directly out of cache without sending those 20+ round trips, and greatly increasing the performance of your application. Notice below in the capture that the request is a cache read only and the expires is six months out.

wa_ibr_4

The catch here would normally be that you wouldn’t be able to do this with content that was updated with even a moderate frequency, let alone dynamic content. Thanks to the magic in IBR that takes it the extra mile, however, this isn’t an issue. You see, if things were as easy as setting a really long cache time on all objects to increase performance, everyone would be doing it. The reality is that kind of cache time has major drawbacks as well. If you set that kind of cache timeout you’re effectively unable to present any new information to your users for that period of time, which is, generally speaking, a very bad thing. IBR solves that problem, however, with hashing.

For each object that IBR alters the cache timeout for, it creates a hash string. This hash string represents the actual object itself, and is appended to the object name. /scripts/base.js becomes /scripts.base.js;wa7YW905BV, for instance. By doing so WA is identifying not only the name of the file being served but the content as well. Periodically as requests for each object come in WA will create a new hash for the objects and check for a difference. If there is a change, it will update the cache to use the new hash, which will automatically cause the browser to download the new version of the file, since the file name is technically different, as far as the browser is concerned. WebAccelerator handles all of the necessary rewriting seamlessly, of course.

wa_ibr_3

At the end of the day you’re left with extremely long cache timeouts on your objects, clients that behave the way you want, namely by serving as much as possible out of local cache which not only dramatically increases application performance and load time, but also reduces server load, and none of the drawbacks and stale content that would normally be associated with setting cache timeouts that would, under other circumstances, be considered irresponsible. That’s IBR for you, and it’s a darn cool tool to have in the toolbox, and all just a checkbox away.

How IBR Works

  • 1. Client X makes a request for a page and all subsequent objects
  • 2. BIG-IP WebAccelerator (WA) forwards the requests to the selected back-end server
  • 3. Server responds to WA with all the objects
  • 4. WA hashes objects according to policy and caches them
  • 5. WA returns them to the client with expiration timers (by policy, default 180 days) and unique URLs for each object (appended strings, typically ;wa……)
  • 6. Client X references local browser cache for those objects defined by WA policy, no round trip necessary
  • 7. Client Y makes a request to WA for the same object, but the object has expired from cache, so WA retrieves the object from the selected back end server
  • 8. Server responds to WA with that object
  • 9. WA hashes the object and compares to the previous version to check for changes. If there is no change the unique identifier/tag (;wa) is not updated but if there is a change a new identifier is created and appended to the object
  • 10. Client X requests the page again
  • 11. WA, already having the object for that page in cache, returns the updated object
  • 12. Client X references newly updated local cache object, again not requiring a round trip to WA for that object