There’s compression, and then there’s compression.

Hand squeezing drip out of spongeOne of the most common means of improving application performance is to reduce the size of the data being exchanged as redress for inherent network protocol behavior that can cause excessive delays in delivery of application data. Compression is often enabled to achieve this goal, and because most data being delivered to applications is text-based (XML, HTML, JSON) this technique generally works quite well. Depending on the architecture of the application delivery network, however, there may be other “types” of compression that can be used in addition to the “compression” typically associated with web-application data.

  • Asymmetric Compression
    Asymmetric Compression is the compression used by most web servers as well as intermediaries claiming the title “application acceleration.” Asymmetric compression is one-sided; it is applied at the server only and uses industry-standard algorithms (deflate, gzip) to compress data before delivery.

    Asymmetric compression is good for web application data because the pattern of data exchanges is heavily weighted on the egress (outbound, response) side of the data exchange. HTTP requests are generally small while the responses are often large and thus the asymmetric nature of this compression is well-suited to these applications.
  • Symmetric Compression
    Symmetric Compression is what is usually implemented by WOC (WAN Optimization Controllers) and primarily works at the network-layer using data de-duplication technologies. These algorithms attempt to reduce the size of data by finding commonly repeated chunks of data and transmitting an “index” or “pointer” to that data rather than the entire data set. One WOC removes the data ,the other replaces it upon receipt. This reduces the amount of data exchanged over the WAN but requires two devices, one at each side of the WAN.

    Symmetric Compression is well-suited for large, repetitive data set exchanges across WAN links, such as commonly shared files/virtual images/etc… shared by multiple users at a remote location.
  • Adaptive Symmetric Compression
    Adaptive Symmetric Compression combines industry standard compression with the network-layer compression traditionally implemented by a WOC and applies it intelligently. Rather than always using a specific algorithm, this capability chooses the algorithm on-demand based on the type of network-link being used and the type of data being exchanged. This means compression will generally not be used on data that does not compress well, such as images (JPG, for example, is already compressed and such files do not benefit from additional compression), and the “best fit” algorithm will be used for other data.

    Adaptive Symmetric Compression is well-suited for environments in which both web-application data and large file sets are being exchanged over the WAN, and excels in environments where more than one WAN link is used.

Comparison of Compression Methods




  • Easy to implement  - can be applied at web server or on most intermediaries (load balancers, for example)
  • Industry-standard
  • Applied to all content, whether advantageous or not
  • Intermediaries must decompress to examine outbound data for viruses and personal information which can add latency to delivery time
  • Transparent to applications
  • Works on all data equally
  • Requires two devices
  • Focuses on network-layer
Adaptive Symmetric
  • Chooses best-fit algorithm based on data and network conditions
  • Transparent to applications
  • Requires two devices

The “danger” with compression algorithms is two-fold. First, applying compression without consideration for the network link and the type of data can actually degrade performance by increasing response times. This is because in some situations it takes longer to apply the compression algorithm to the data than it would to transfer the raw data across the given link. Second, the location within the network where compression is applied can have a deleterious effect on other infrastructure components attempting to act on the data, because it must decompress the data, apply its policies, and then recompress the data. This is similar to the problem of end-to-end SSL encryption of data, which forces intermediaries either to abandon their function (a bad idea) or to decrypt, execute, then re-encrypt data.

Choosing the right compression strategy to fit with your architecture, data, and application needs is paramount to ensuring that the benefits of compression are realized. 

WILS: Write It Like Seth. Seth Godin always gets his point across with brevity and wit. WILS is an ATTEMPT TO BE concise about application delivery TOPICS AND just get straight to the point. NO DILLY DALLYING AROUND.