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

This is article seven 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.



Rounding out the WebAccelerator series is a dose of what was learned along our own journey into the wilds of Web Application Optimization. Some things to keep in mind as far as how to achieve what you’re looking for, a few others that might have you scratching your head and perhaps we can save you some time. WebAccelerator is a powerful, flexible technology and with that comes a certain level of intricacy and experience needed to master the nuances. While I’m no master, I’d like to at least share what I’ve picked up so far.

Dawn Says...


I’ve been working in the acceleration and optimization space for what seems like forever, much has changed during this time but a few things haven’t:

  • There is no one-size-fits all solution. Optimizing an application is a very individual process, no two applications will show the same performance gains. My stock answer when asked the inevitable question of “How much faster will my application be after I optimize it?” is it depends. It depends on what has already been optimized, it depends on what the current metrics are, it depends on where your users are located and how they are accessing the application.
  • Optimizing an application is an art not a science. You really need to understand an application, HTTP headers, and HTML to fine tune an application. Make a change to a value, run some tests and see what it changed. The minimum acceptable quality rating for JPEGs may be different from one application to another and from one organization to another.
  • Test, test and test again. Changes should be made one at a time to see the impact on the application both from a functional and a performance perspective. With incremental testing it is easy to know what “broke” an application and see whether a given feature improves any of the key metrics being evaluated. Tests should be conducted from a single user perspective, under load and from various latencies and geographies. Testing page load time difference from a high speed LAN connection with no latency will most likely show very little differences. Testing from where your users are is what is most important.

First off, the thing that took me probably the longest to get truly comfortable with was the policy editor. It’s well laid out and works nicely, but there are just so many options to sort through, and a few nuances to go along with them. Allow me to shine a little light here and there. Firstly, many of the features you’re looking to apply to your application content, such as compression, IBR, Caching, etc. may be enabled at a high level, but if they aren’t enabled in the “pages-assembly” view, you aren’t parsing pages, and things won’t fire the way you’re expecting. Also, if they aren’t enabled for the HTML node in the navigation tree, none of your HTML content is going to be parsed to benefit from those particular features.

This is true, actually, for each individual component type; images, includes, etc. Each of them allow for options to be selected at a granular level, and that can cause some confusion if you have settings applied differently at, say, the global level than at the images level. Make sure you’re configuration is in synch across tiers in the tree. And while we’re talking about tiers in the tree in the editor, there is parent to child inherency, which is a good thing. It’s important to note, however, that this only occurs at create time, not at save or load time. This caused a bit of confusion the first time I encountered it.

Also worth noting is that if you want to enable either caching or compression via WA, you’ll need to enable those profiles on your Virtual IP as well as in the WA configuration. If TMM isn’t flagged to compress, WA can’t force it to do so. However, if it is flagged to compress, WA’s settings will take precedence over whatever compression profile is applied. The same goes for caching.

One last gotcha, that will likely only affect a few people, is in regards to IBR. There is a nuance type option when enabling IBR. You get to choose from “Enable IBR within” or “Enable IBR to”. The difference here wasn’t clear at first, but Dawn, one of our resident WA experts was able to clear it up for me. “Enable IBR within” equates to parsing the object at hand and re-writing it so that every link contained with the object, a css file for example, is affected by IBR. This means it will parse the object and change every link to a ;waxxx… enabled link (re-naming the file to include the ;wa tag hash, indicating IBR as active for that object) so that it can be tracked via IBR and cached appropriately. This is, most times, overkill. It is there as a special case but more often than not the option you’ll want is “Enable IBR to”, which means to IBR cache and hash the particular file type in question as a singular object, rather than parsing it.

As far as a handy trick that I picked up while doing some WebAccelerator testing, I can’t tell you how helpful it was to turn the x-wa-info headers on. This is done in “Applications” under advanced. Doing so makes it amazingly easy to see that WA is working. And to see just what it is doing when it is working, here’s a little hint: a header beginning with 102 indicates a response generated from the back-end webservers. A 101 or 111 header is being served from the cache.

Jason Says...


As Colin indicated, there is a plethora of data in those x-wa-info headers, and the details for all the particular fields can be found in the WA systems concept manual or in Solution 13798. Or if you don't like to RTFM, there is a handy cli tool introduced in v11 called wainfodecode that'll do all the hard work for you. Just extract the header value from X-WA-Info and run the command to get the details for that object's interaction with WAwa_tipstricks_1


# wainfodecode "[V2.S10203.A93066.P89721.N13478.RN0.U0].[OT/html.OG/pages]"
V2: X-WA-Info Format Version
S10203: Response was served from the origin web server, as dictated by an acceleration policy rule.
A93066: Application: /Common/dc.wa_v2
P89721: Local-policy: /Common/dc.wa_v2
N13478: Request Policy Node: Pages
RN0: Response match did not supersede request match
UCI hash: 0
Object type: html
Object group: pages

Armed with that info it became very easy to determine exactly what the WebAccelerator was doing for each page and object. There you have it, hard earned knowledge from our time in the trenches with WebAccelerator. Take it, use it, spread the word, and go forth and prosper with it in a wonderfully accelerated fashion.