Manual Chapter : Compression

Applies To:

Show Versions Show Versions

BIG-IP AAM

  • 14.0.1, 14.0.0

BIG-IP APM

  • 14.0.1, 14.0.0

BIG-IP Analytics

  • 14.0.1, 14.0.0

BIG-IP LTM

  • 14.0.1, 14.0.0

BIG-IP PEM

  • 14.0.1, 14.0.0

BIG-IP AFM

  • 14.0.1, 14.0.0

BIG-IP DNS

  • 14.0.1, 14.0.0

BIG-IP ASM

  • 14.0.1, 14.0.0
Manual Chapter

Compression

About data compression strategies

If you need more control over the way that the BIG-IP® system compresses data than what the standard HTTP compression profile configuration provides, you can use the Traffic Management Shell (
tmsh
) to enable a compression strategy other than the default strategy.
You can choose from five compression strategies: Latency, Speed, Size, Ratio, and Adaptive. The default compression strategy is Latency. The BIG-IP system uses the compression strategy that you select to determine which compression provider (hardware compression or software compression) to use for a given HTTP response. Once an HTTP response is assigned to a compression provider, the response remains associated with that compression provider until the response completes.

Set the data compression strategy

You can use
tmsh
to set a compression strategy other than the default. The default compression strategy is Latency.
  1. Open the TMOS Shell (
    tmsh
    ).
    tmsh
  2. Set a specified compression strategy.
    sys modify db compression.strategy
    value
    [ latency | speed | size | ratio | adaptive ]
    This example enables the Adaptive compression strategy:
    sys modify db compression.strategy value adaptive

Available compression strategies

When using
tmsh
to configure compression for a BIG-IP® system, you can choose from these compression strategies.
Compression strategy
Description
Latency
This is the default compression strategy. The system favors the latency of compression providers and delays selection of a provider until data arrives. This strategy helps to better distribute the workload placed on each provider. Since each provider has different compression capabilities (for example, different potential throughput), this strategy focuses on the total throughput of the device by keeping metrics on the current throughput level of all requests combined. As the device approaches its theoretical work limit, the provider becomes less favorable by the strategy, and new work is assigned to the least busy provider.
The Latency strategy provides a better throttle mechanism when a large number of compression requests are in the queue.
Speed
The system uses the hardware compression provider to the fullest extent possible. Only when the hardware is busy does the system use a software compression provider to compress HTTP server responses. The Speed strategy is best used for bulk compression and for limiting CPU overhead.
Size
The system performs as much compression in the software as possible using a ratio of TMM and Offload. Only when the software is busy does the system use the hardware compression provider to compress HTTP server responses. The Size strategy gives the best ratio at the expense of CPU overhead.
Ratio
The system uses a weighted round robin approach to decide which compression provider to use to compress data. The Ratio strategy limits CPU overhead while giving good compression ratios.
Adaptive
The system first uses a software compression provider to compress HTTP server responses. The system switches to the hardware compression providers based on both the gzip compression level that you set in the HTTP compression profile and the hardware compression provider that the system contains. As load on the system increases, the system responds by reducing the desired gzip compression level (specified in the HTTP compression profile). The system uses the hardware compression provider only when that provider can deliver the specified or systematically-reduced gzip compression level.
The Adaptive strategy gives you the most control over how LTM handles compression.