Search
Lori MacVittie - Two Different Socks
You are here: DevCentral > Weblogs

posted on Tuesday, February 23, 2010 3:48 AM

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

 

PROS

CONS

Asymmetric
  • 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
Symmetric
  • 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.


Related blogs & articles:

Follow me on Twitter    View Lori's profile on SlideShare  friendfeed icon_facebook

AddThis Feed Button Bookmark and Share



Feedback

5/11/2010 2:09 PM
Gravatar CloudFucius Wants: An Optimized Cloud
Pete Silva

Let Me Know What You Think


Please use the form below if you have any comments, questions, or suggestions.

Title:
 
Name:
 
Email: (so we can show your gravatar)
Website:
Comment: Allowed tags: blockquote, a, strong, em, p, u, strike, super, sub, code
 
Please add 5 and 4 and type the answer here:

Blog Stats

Posts:980
Comments:1685
Stories:0
Trackbacks:583
  

Image Galleries

  

Application Delivery

  

Cloud Computing

  

Random

  

Security

  

Chat Catcher

82,243 Members in 102 Countries and Growing!

Join DevCentral Today!

About DevCentral

DevCentral has been a successful, thriving community for many years. We have always strived to bring you the best technical documentation, discussion forums, blogs, media and much more that we can.

So dive in, get familiar with DevCentral. We hope you like it, we hope it makes your job easier, and lets you get that much more power out of the community. To learn more, make sure to check out the Getting Started section. And if you have any problems, or think something could be easier to use, drop us a line to let us know.

Got It !

We've received your comment and transmitted it directly to DevCentral HQ.

Thanks for taking time to let us know what's on your mind. At DevCentral | Community Matters!

Get In Touch With Us

Have questions, suggestions or just want to get something off your chest?

Use our handy form below to Direct Connect with DevCentral Mission Control.

Send Us Feedback       or