I have used the WAM (WebAccelerator Module) to accelerate a few SharePoint 2007 sites in the past and have been able to achieve a 45%-55% reduction in the number of hits on our web front end servers.  To me that is a pretty dramatic reduction to say the least.  Those servers have since been upgraded to SharePoint 2010 so I will hopefully be doing another blog post in a few weeks where I will show you how we use WAM to accelerate SharePoint 2010 web applications.  In this post I am going to cover using the default WAM IIS template to accelerate our main web site and show you the results.

Previously I was using TMOS Version 9.x so starting off couldn’t be more simple in Version 10.2.  One very nice thing that I want to point out with this version is that when you click on the WebAccelerator section in the GUI it no longer opens up in a separate window.  That used to really annoy me and I was glad to see it is more cohesive in this version.  After clicking into there, click the “Applications” menu option and then click “Create”.  Type in a name, select the central policy template that you want to use (MS IIS in my case), type in your requested host name and click save.

You then create a Class Profile by clicking “Class Profiles” and “Create”.  Assign a name to it and leave the default values as they are.  That way if you decide to change  or modify something in that profile in the future you can easily do so and it will not effect any of your other profiles.  Then go back into the Local Traffic portion of the GUI, select the Virtual Server that you want to add the policy to, click “Resources” and then click the “Manage” button under HTTP Class Profiles, select the newly created acceleration profile in the list, click the << button to add it to the list and then click the finished button.

That’s it ladies and gentlemen!  You now have a accelerated web site.  How easy is that?!  I can’t imagine it being any easier than that, of course those folks at F5 Networks are always improving things.

So what kind of results can you expect from such a simple setup?  Well lets take a look.  From the graphs below you can see that the BIG-IP WAM has a response time of about 21ms for content requests.  This is the length of time it takes the WebAccelerator system to respond to a request from the client.

The second picture below shows you that the unit responded to 48,000 requests and the unit was able to successfully accelerate around 37,000 requests via Smart Cache.  That is a lot of happy users and represents 37,000 requests that our web servers did not have to respond to!  The errors that show up in the report are mostly my fault because I have not cleaned up my traffic reports like George Watkins explains how to do over on DevCentral http://devcentral.f5.com/weblogs/watkins/archive/2010/08/18/clean-up-those-webaccelerator-performance-reports.aspx.  Thanks again George for that excellent post!  Once I have had a chance to clean those reports up I will try to post a prettier picture.

Then last but certainly not least, is a picture that shows you my CPU utilization on that particular unit over the last 24 hours.  This picture was taken roughly 9 hours after implementing the web acceleration profile.  As you can see there has been only a slight increase (maybe 1%) in my CPU utilization.

Looking at those facts it is safe to say this was a very successful deployment of a WAM profile on a production web site that has generated some very positive results.  Faster responses for the end users and less load on the back web servers, it is a win-win solution in my book.

For those who haven’t had a chance to examine the file at length, the globalfragment.xml file is basically a roadmap that the WebAccelerator module can read to know how to handle or classify different file types.  If you want the WebAccelerator recognize and classify a particular file type it would be good for it to be defined in this file.

If you take the upgrade path I mentioned above, it might be wise to make a backup copy of that particular file first.  The file can be found in the “/config/wa/” directory.  It is possible for that file to be overwritten during the upgrade and if you have custom entries defined in it… well you get the picture!

Unbeknownst to me, custom entries had been inserted into that file for .wmv files at some earlier date.  Shortly after the upgrade of course, .wmv files stopped streaming properly from virtual servers utilizing WebAccelerator based HTTP class profiles.  So I took the profiles off the virtual servers in question and contacted F5 Networks Support.  I was unaware of how the WebAccelerator module used the globalfragments.xml file until I was educated by an excellent F5 Networks Senior Network Support Engineer about it.

I added the entries back for the .wmv files, reapplied the HTTP class profiles that I had disabled during troubleshooting and everything worked like a charm.  The Engineer was also kind enough to create CR12834 to add .wmv files to the stock list of file types into future TMOS versions.  Thanks again to Dale Anderson for all your help!

If you are having trouble with certain file types after applying a WebAcceleration HTTP class profile then you might take a peek at the globalfragments.xml file and ensure the file type is defined correctly within.

This issue and the one mentioned in my previous post are the only two issues that I had from upgrading from version 9.4.4 to version 9.4.8!

The unit that was upgraded has three modules running on it, the GTM, LTM and WA modules.  The issue is caused by the WebAccelerator module logging to many messages out to the PVAC log, which can lead to excessive disk I/O and may cause the log file to grow so large it crashes the WebAccelerator module.  It is now a Known Issue and is being tracked in CR127854.  So if you have upgraded to TMOS 9.4.8 and you are running the WebAcceleration module you might want to keep an eye out for this!

If you believe you have a unit experiencing this issue I would advise you to contact F5 Technical Support and open a case with them.  An Engineering Hotfix can be provided to you that addresses this issue.  In the meantime, if you are able to stop using the WebAccelerator class profiles, then I would suggest not using those until you have downloaded and applied the hotfix.  Below is the text from AskF5.com regarding the issue.

Known Issue
Updated: 9/17/09 10:11 AM