WA and Yahoo's exceptional performance rules

I've been following Steve's blog for awhile and he does have some good suggestions on optimization many of which are available via WebAccelerator. Of the items listed on the best practices WebAccelerator and LTM can handle many of these.

 

 

1.Make Fewer HTTP Requests/Configure eTags/Add Expires or Cache-Control Header/Make AJAX Cacheable

 

This is achieved for repeat visitors via Intelligent Browser Referencing. WebAccelerator will insert cache-control headers and eTags into static content to ensure it is cacheable by browsers. The policies provide granular control over which types of data are cacheable and which types are not. Intelligent Browser Referencing also ensures that when a file changes the user will receive instructions that the file cached on the browser is out of date and a new version needs to be downloaded.

 

 

2. Gzip Components

 

Many policies by default enable compression on HTML, JavaScript, Stylesheets, and many other text files.

 

 

3. Split Components Across Domains

 

MultiConnect provides this functionality by spreading static content across multiple domains enabling the browser to download more than 2 items at a time. This is recommended in instances when there is a large number of objects on the page and a high percentage of first time visitors, repeat users will be loading most content from the browser cache as a result of item 1. It should be noted that enabling this negates the recommendation to reduce DNS lookups. Spreading content across domains creates additional DNS lookups.

 

 

4. No 404s

 

With an iRule the 404 can be changed into a 200 response code that is then considered cacheable by WebAccelerator saving the backend resources from continually processing requests for an object that does not exist.

 

 

5. Make favicon small and cacheable

 

WebAccelerator can not help with the size of the file but it can assist in making this cacheable. With IBR the favicon can be cached on both WebAccelerator and the client's browser for very long periods of time, if the object changes the browser will request the new version.

 

 

6. Use a Content Delivery Network

 

A symmetric deployment of WebAccelerators will achieve the same results as using a content delivery network by positioning the data closer to the end users. GTM can be used to direct users to closest WebAccelerator.

 

 

Some of the other recommendations may be achievable through iRules or future feature enhancements

 

 

Thank you for the feedback.

 

 

Now all this talk about caching has me considering all my involvement with the creative folks who will modify an existing file and retain the same name. Then they undoubtedly would wonder why they would not be able to see their changes, is there a way to bust the cache in such cases and force the client to get the new content? Is this functionality available at an object level or a larger level, or does it just figure it out automagically?

 

 

Thanks,

 

 

Carl B

The battle with creative folks exists in many organizations which is why WebAccelerator has been designed to give you the best of both worlds. The creative folks are able to modify an existing object without changing the name and you can still utilize caching on WebAccelerator and the browser. This is accomplished through 2 methods - intelligent browser referencing and invalidations. From the WebAccelerator cache perspective invalidation triggers can be written into the policy or through a stand alone application. These invalidations are triggered when a certain page is hit in the application or an item is published to the database or the content managemetn system, the invalidation can be for a specific item, for an entire directory or for the entire site. This invalidation message tells WebAccelerator that content that matches the invalidation trigger is no longer valid and needs to be refreshed from the origin server on the next request.

 

 

The Intelligent Browser Referencing is re-writing the uri for the image with a very specific hash, when the object changes the hash will be different. For example the browser receives an image with the uri 'image1.gif;abcdefghijkl' this is written to the browsers cache for a period of time. When the object is upadted the hash value that is created will be different as the object has a new size, last modified date, etc. The uri for the image will now be 'image1.gif;zyxwvu' this is an object that does not exist in the browser cache so a full GET request will be issued for this new object.

 

 

The combination of invalidating content and Intelligent Browser Referncing allows the creative folks to change items and instantly see their changes when they next visit the page instead of the old cached version.