Configure F5 BigIP Compression For Maximum Performance

From RZWiki

Here you'll find useful information on configuring HTTP compression on an F5 BigIP to maximise performance as well as avoid common mistakes and issues.

Compression Client Support

As compression support is optional in the HTTP/1.0 specification (RFC1945) you should assume HTTP/1.0 only capable clients will not support compression (the notable exception being Netscape 4.)

Of lesser importance, the HTTP/1.0 compression Headers are the same as that used in HTTP/1.1 (Accept-Encoding: and Content-Encoding:) however, the supported values are different: x-gzip, x-compress and token. A value of gzip should be considered and handled in the same way as an x-gzip value for future compatibility but again, this may not be implemented on some clients.

Even HTTP/1.1 (RFC2616) capable clients may send/make HTTP/1.0 requests depending on configuration. I've seen this frequently with IE6.

font color=redNote Microsoft Internet Explorer, including v7, does not support any Vary header (related to compression and other HTTP features) value other than User Agent, in isolation. If any other, or more than one value is present in this header, browser caching will not occur and content may not display in external programs launched by IE./font See the Disable Vary Header Insertion By Apache For MSIE Clients and Disable Vary Header Insertion By F5 BigIP for information on how to overcome this issue for these platforms.

Also note Microsoft Internet Explorer v6 and v7 frequently make HTTP/1.0 requests for the reasons described in this Knowledge Base article: http://support.microsoft.com/kb/947513, which also describes how to fix this issue. Keep this in mind when dealing with compression and caching issues with these browsers.

Other potential issues can be found in our Web Applications Troubleshooting article. noinclude/noinclude

Chunking

Chunking allows a server to start sending (chunks of) response data before it knows the final size of the content that's being sent (which can occur frequently with dynamically generated content.) With chunking, responses are sent with a Transfer Encoding HTTP header value of chunked and chunk data length information in the payload.

You cannot select the Preserve value for the Response Chunking setting because compression will change the length of the chunk(s).

The Selective value is recommended as this only rechunks data if the response payload has been modified (which should only happen if compression has taken place) and if the server response was itself chunked. Responses that the server did not chunk will have the value of their Content Length HTTP header rewritten accordingly.

The Rechunk value is not recommended as even data that has not been chunked by the server will have the chunk related HTTP header and data length information added, increasing the response size unnecessarily. UNote:/U LTM Versions up to v9.4.5 ignore the Minimum Content Length value if Response Chunking is configured to Rechunk.

The Unchunk value is not recommended as this would result in client-side connection closure after every response (as this would be the only way to indicate the end of the response content.)

Chosing A Compression Library

deflate (based on zlib) is preferrable to gzip as gzip uses the deflate algorithm anyway but is generally slower due to its use of larger headers and trailers and a slower integrity check (aka checksum) compared to zlib (mod_deflate) used alone. See our Zlib Compression Overhead and Gzip Compression Overhead articles for more information on these overheads.

UNote:/U Although their names suggest otherwise, the gzip Compression Level, Memory Level and Window Size settings do apply to deflate.

Identifying What To Compress

Two methods can be used by the BigIP to identify what traffic or data should be compressed. UNote:/U If neither method is enabled, all content is compressed;

By Content Type

Using this method, the BigIP inspects the HTTP Content-Type header in server responses to clients and compresses content if the value of this header matches one of the values in the Content Include List configured in the HTTP profile on the device.

Note values in the Content Exclude list take precendence over values in the Content Include list.

Valid values that can be added to the Content List are actually IANA standard media/mime type values. A full list can be found here: http://www.iana.org/assignments/media-types/.

The default values in the Content Include List are shown below and will ensure nearly all text-based server responses are compressed, note the supported use of a regular expression;

application/(xml|x-javascript)
text/

If you serve SVG images its worth adding the following to the Content Include List as SVG files are actually XML text files that describe an image;

image/svg+xml

If your back end web servers are running IIS and ASP.Net, you'll probably observe this content type being used and may wish to add it to the Content Include List;

application/x-www-form-urlencoded

If you serve Microsoft documents, you may wish to add the following to the Content Include List;

application/msword
application/vnd.ms-excel
application/vnd.ms-powerpoint
application/vnd.ms-project
application/vnd.ms-xpsdocument

If you serve Flash content, you may wish to add the following to the Content Include List;

application/x-shockwave-flash

I wouldn't recommend it but if you wanted to compress everything, you would add this to the Content Include List;

*/*

By URI

If the majority of server responses do not contain a Content-Type HTTP header for some reason, the BigIP can inspect the URI of server responses and compress content if some or all of the URI matches one of the values in the URI List configured in the HTTP profile on the device.

Note values in the URI Exclude list take precendence over values in the URI Include list.

Adding the values below to the URI Include list will ensure nearly all text-based server responses are compressed;

*.htm
*.html
*.shtml
*.css
*.js
*.jsp
*.xml
*.txt
*.asp
*.aspx

If you serve SVG images its worth adding the following to the URI Include List as SVG files are actually XML text files that describe an image;

*.svg

If you serve Microsoft documents, you may wish to add the following to the URI Include List;

*.doc
*.xls
*.ppt
*.ppt
*.xps
*.odf

If you serve Flash content, you may wish to add the following to the URI Include List;

*.swf

What To Not Compress

As they are already compressed, you should not configure compression for the following;

• Image files, (except SVG)
• Adobe PDF files

Vary Header

If you have Internet Explorer clients, do not enable the insertion of a Vary Header (with the value: Accept-Encoding.) See the Browser Caching section of the Web Applications Troubleshooting article for more information on why you shouldn't.

HTTP/1.0 Requests

Most HTTP/1.0 clients do not support compression and this setting is likely to have very little if any affect if enabled. However, there is every chance compressing responses sent to older HTTP/1.0 clients that do support compression will cause issues as in most cases it is poorly implemented and breaks other features such as caching.

Browser Workarounds

This feature generally doesn't work very well and disables compression unnecessarily in many cases. Unless you experience frequent client issues related to compression this feature should be disabled.

Other Settings

The Keep Accept Encoding setting determines if the Accept-Encoding HTTP header in client requests is kept or discarded when the request is forwarded to a server. If this setting is enabled and the server supports compression, responses will be compressed twice, once by the server and once by the F5 BigIP.

Example Compression Profile Configuration

The following command creates an HTTP profile call http_compression_no_images with settings that incorporate the recommendations above;

b profile http http_compression_no_images \{ oneconnect transformations disable compress enable compress prefer deflate compress min size 1024 compress buffer size 8192 compress vary header disable compress http 1.0 enable compress gzip memory level 8k compress gzip window size 16k compress gzip level 6 compress keep accept encoding disable compress browser workarounds disable response selective chunk pipelining enable compress content type include application/\(xml\|x-javascript\) text/\* application/http application/x-shockwave-flash application/msword application/vnd.ms-excel application/vnd.ms-powerpoint application/vnd.ms-project application/vnd.ms-xpsdocument \}

Note relevant characters have been escaped based on the assumption the bigpipe shell is not being used.

Usage Notes

It is unclear what happens if both URI and Content Type compression are configured.

font color=redEnsure the Compression Buffer Size value is large enough to hold the entirety of the largest possible server response/font. If it is not considerable performance issues can occur.

HTTP Headers are not compressed.

Further Information

Refer to the latest F5 BigIP Command Line Interface Guide for information on how to enable adaptive compression on F5 BigIPs with hardware compression providers.

Compression Statistics

Use the bigpipe http command to view historical compression statistics. Also refer to the Viewing Statistics, F5 BigIP article for additional information on calculating other compression metrics.

Use the tmstat command to view real time compression statistics.

Related Commands

Use the bigpipe profile command to display, create or modify HTTP profiles which contain compression settings.

Use the bigpipe virtual command to assign HTTP profiles to virtual servers.

Related Articles

Take a look at our other Performance related articles

Information on F5 BigIP commands

Information on Linux commands

Information on Cisco commands

Information on Windows commands

Information on Vyatta commands

Information on Extreme commands

Information on Nortel commands

Information on Zebra commands

Information on Secure Platform commands

Information on Blue Coat SGOS commands

Information on Nokia IPSO commands

We really do appreciate all feedback so please do send your comments, suggestions or corrections to sjiveson#routerzone.eu (replacing the # with an @)