Akamai Diversity

The Akamai Blog

Are you leaving web performance on the table?

The surge in Microsoft [IIS] install base gains reported in the Netcraft February 2014 Web Server Survey presents an opportune time to write about a lesser known behavioral interaction between IIS and Caching Web Proxies as well as other layer 7 network intermediaries that operate similarly.  The interaction in question is related to HTTP compression being disabled whenever an HTTP Via header is included in inbound request to the server.  According to this Microsoft TechNet article, the intent is to "minimize the chance of inappropriately returning a compressed file to a client that cannot decompress it because not all caching proxy servers handle the caching of compressed objects correctly".  However, for intermediaries like the Akamai Intelligent IP Platform that have highly advanced caching and other network optimization capabilities, the origin not sending compressed content can have a negative effect on the total achievable performance.


The behavioral difference can be easily illustrated by looking at individual object response times, and while the effect may not be specifically additive for web pages or applications that contain rich content due to concurrent HTTP connections supported by modern browsers, the difference is enough to verify and take action on if required.  The approach is to request a compressible object and see if the response is compressed both with and without the Via header.

Using a common command line client, curl, the two requests would look like:

Request 1: Simulated direct request: 
curl -I -H "Accept-Encoding: gzip" --user-agent "Mozilla/5.0" "http://my.iis_server.com"

Request 2: Simulated proxied request:
curl -I -H "Accept-Encoding: gzip" -H "Via: Akamai" --user-agent "Mozilla/5.0" " http://my.iis_server.com" 

This example assumes that the default page is in fact compressible, which would be evidenced in the Content-Encoding: gzip response header.  If the behavior is different than request 2, then you'll want to make necessary adjustments detailed below.

The actual impact on response time can be further shown through a simple script:

#!/bin/bash

ORIGIN="int.iis_server.com";

VIA=`curl -o /dev/null -s -w %{time_connect}:%{time_starttransfer}:%{time_total} -H "ext.iis_server.com" -H "Accept-Encoding: gzip" -H "Via: Akamai" --user-agent "Mozilla/5.0" http://$ORIGIN`;
DIRECT=`curl -o /dev/null -s -w %{time_connect}:%{time_starttransfer}:%{time_total} -H "ext.iis_server.com" -H "Accept-Encoding: gzip" --user-agent "Mozilla/5.0" http://$ORIGIN`;

echo -e "VIA_Connect\011Via_Transfer\011Via_Total "
echo $VIA | awk -F:  '{ print $1 "\011\011" $2 "\011\011" $3}'
echo -e "DIRECT_Connect\011DIRECT_Transfer\011DIRECT_Total"
echo $DIRECT | awk -F:  '{ print $1"\011\011"$2"\011\011"$3}'

When executed, this will produce something similar to the following output:
VIA_Connect           Via_Transfer            Via_Total 
0.097                        0.439                       0.628
DIRECT_Connect    DIRECT_Transfer    DIRECT_Total
0.091                        0.379                       0.471

The reason for this discrepancy can be easily seen in the delta between the Content-Length headers in the two responses.  Compressed this file weighs in at 5k while uncompressed  it is 17k.  So the actual impact on performance is directly proportional to the overall page weight of compressible objects.  Now that you have discovered there is in fact a performance degradation there are a couple options.

  1. Akamai customers can have standard meta data added to their configuration to remove the Via header entirely for origin forward requests assuming that there is no other purpose being used for that header.  This fix is detailed in Knowledge Base article ID #966 internal notes section which you can reference in your Technical Support Case.
  2. Make the configuration change on the origin side.  Techniques for doing this vary slightly from one version of IIS to the next, but at a high level:
  For IIS 6, Set the HcNoCompressionForProxies metabase property to false 
  For IIS7, both noCompressionForHttp10 and noCompressionForProxies need to be set to false



*  [ Netcraft February 2014 Web Server Survey - http://news.netcraft.com/archives/2014/02/03/february-2014-web-server-survey.html ]
**[Technet Article Title - http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/25d2170b-09c0-45fd-8da4-898cf9a7d568.mspx ]

Leave a comment