Manual Chapter :
Compression
Applies To:
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
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.- Open the TMOS Shell (tmsh).tmsh
- Set a specified compression strategy.sys modify db compression.strategyvalue[ 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. |
