11-11-2013 02:49 AM
We have built a simple one-arm PAT config to round robin load balance two Varnish servers. In the "Default L7 load-balancing action" we have left compression to "N/A". It looks like the ACE removes "Accept-Encoding: gzip, deflate" from the client header.
Is this normal behaviour? We would like the Varnish to do the compression. Do we need modify the headers to get this through the ACE?
11-11-2013 05:10 AM
Hi,
Yes this does seem to be the behavior. Please read below:
HTTP compression is a capability built into web servers and web browsers to improve site performance by reducing the amount of time required to transfer data between the server and the client. Performing compression on the ACE offloads that work from the server, thereby freeing up the server to provide other services to clients and helping to maintain fast server response times.
When you enable HTTP compression on the ACE, the appliance overwrites the client request with "Accept-Encoding identity" and turns off compression on the server-side connection. HTTP compression reduces the bandwidth associated with a web content transfer from the ACE to the client.
So ACE rewrites the ACCEPT-ENCODING header to IDENTITY to indicate to the server that it should not compress the return data. That would be done by ACE.
Also, default method is used when client comes with both gzip or deflate for "ACCEPT ENCODING". For compression to work, a client must send a request with an ACCEPT-ENCODING method of gzip or deflate. If a client sends both methods, then the ACE uses the configured method(default method).
Also, you can see if ACE is compressing the packets or in "show service-policy
switch/Admin#
show service-policy L7_COMP_SLB_POLICY detail
Status : ACTIVE
Description: -----------------------------------------
Interface: vlan 1 108
service-policy: L7_COMP_SLB_POLICY
class: vip
VIP Address: Protocol: Port:
2.0.5.1 tcp eq 80
loadbalance:
L7 loadbalance policy: pm
VIP ICMP Reply : ENABLED
VIP state: OUTOFSERVICE
Persistence Rebalance: ENABLED
curr conns : 0 , hit count : 0
dropped conns : 0
client pkt count : 0 , client byte count: 0
server pkt count : 0 , server byte count: 0
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0
L7 Loadbalance policy : pm
class/match : h
ssl-proxy client : c
LB action :
primary serverfarm: sf1
state: DOWN
backup serverfarm : -
hit count : 0
dropped conns : 0
compression : on <------------------------------ Compression is enabled if the value is "on"
compression bytes_in : 0 bytes_out : 0 <--- Number of bytes transmitted after compressing the server response
Compression ratio : 0.00% <------------------------------ Percentage of data compressed
Gzip: 0 Deflate: 0 <--------------- Number of times the method is used
compression errors: _
User-Agent : 0 Accept-Encoding : 0 |
Content size: 0 Content type : 0 |
Not HTTP 1.1: 0 HTTP response error: 0 |-- Check these error counters to see if they are increasing
Let me know if you have any questions.
Regards,
Kanwal
11-11-2013 06:32 AM
Probably true if you enable compression but we have not.
After capturing some traffic I concluded that the ACE surely had NOT rewritten the headers. Request headers - all the way from client, through ACE and Varnish servers - still had "Accept-Encoding: gzip, deflate" unaltered.
In some cases though the IIS that delivers the html data decides to compress the data, in some cases it simply refuse.
In all tests we have done the request contains "Accept-Encoding: gzip, deflate" so it's at the IIS that is the problem here.
Thanks anyway Kanwal for clarifying.
11-11-2013 06:34 AM
Hi,
Yeah without compression ACE shall not touch the "Accept Encoding" Header.
Regards,
Kanwal
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide