Selective Compression on BIG-IP

BIG-IP provides Local Traffic Policies that simplify the way in which you can manage traffic associated with a virtual server.

You can associate a BIG-IP local traffic policy to support selective compression for types of content that can benefit from compression, like HTML, XML, and CSS stylesheets. These file types can realize performance improvements, especially across slow connections, by compressing them. You can easily configure your BIG-IP system to use a simple Local Traffic Policy that selectively compresses these file types. In order to use a policy, you will want to create and configure a draft policy, publish that policy, and then associate the policy with a virtual server in BIG-IP v12.

Alright, let’s log into a BIG-IP

The first thing you’ll need to do is create a draft policy. On the main menu select Local Traffic>Policies>Policy List and then the Create or + button.

This takes us to the create policy config screen. We’ll name the policy SelectiveCompression, add a description like ‘This policy compresses file types,’ and we’ll leave the Strategy as the default of Execute First matching rule. This is so the policy uses the first rule that matches the request. Click Create Policy which saves the policy to the policies list.

When saved, the Rules search field appears but has no rules. Click Create under Rules.

This brings us to the Rules General Properties area of the policy. We’ll give this rule a name (CompressFiles) and then the first settings we need to configure are the conditions that need to match the request. Click the + button to associate file types.

We know that the files for compression are comprised of specific file types associated with a content type HTTP Header. We choose HTTP Header and select Content-Type in the Named field. Select ‘begins with’ next and type ‘text/’ for the condition and compress at the ‘response’ time. We’ll add another condition to manage CPU usage effectively. So we click CPU Usage from the list with a duration of 1 minute with a conditional operator of ‘less than or equal to’ 5 as the usage level at response time.

Next under Do the following, click the create + button to create a new action when those conditions are met. Here, we’ll enable compression at the response time. Click Save.

Now the draft policy screen appears with the General Properties and a list of rules. Here we want to click Save Draft.

Now we need to publish the draft policy and associate it with a virtual server. Select the policy and click Publish.

Next, on the main menu click Local Traffic>Virtual Servers>Virtual Server List and click the name of the virtual server you’d like to associate for the policy.

On the menu bar click Resources and for Policies click Manage.

Move SelectiveCompression to the Enabled list and click Finished.

The SelectiveCompression policy is now listed in the policies list which is now associated with the chosen virtual server. The virtual server with the SelectiveCompression Local Traffic Policy will compress the file types you specified.

Congrats! You’ve now added a local traffic policy for selective compression! You can also watch the full video demo thanks to our TechPubs team.

ps

Published Oct 17, 2017
Version 1.0

Was this article helpful?

7 Comments

  • Does this mean that you don't need to assign an HTTP Compression Profile on the virtual server?

     

  • PSilva's avatar
    PSilva
    Ret. Employee

    Thanks for the note Walter.

     

    From my good buddy Jason Rahm: Objects assigned to vips are default behaviors. Policies/iRules can alter that behavior or establish it if you don't want default behaviors attached to the vip. It comes down to domains of control. If some logic is in vip, other in policy, and yet other in iRule, it can be confusing to see the whole picture, so some choose to put it all in one place.

     

    The optimized path however is a) put as much control at vip, b) then policy, c) then iRule...and then document it well. :-)

     

    ps

     

  • It could, but it would eat a large amount of CPU since PDFs are usually static and large. It would be best to discuss with your app team on build the documents more efficiently. If you must compress PDFs, I would suggest HTTP Compression along with WebAcceleration profiles. This will allow the compressed content to be cached in BIG-IP.

     

  • Would it have any specific KBs that efficiently demonstrate this compression of .pdf articles by AAM?

     

  • AAM does additional PDF compression and caches the result in RamCache (which is the backing store of the WebAcceleration profiles) However, AAM has been withdrawn from marking and will be removed in a future product version. Are you already using AAM in your environment?