On Mon, Jul 14, 2008 at 10:04:43AM +0800, Jeffrey 'jf' Lim wrote:
> On Wed, Jul 9, 2008 at 11:42 AM, Jeffrey 'jf' Lim <jfs.world#gmail.com>
> > On Wed, Jul 9, 2008 at 11:20 AM, Jeffrey 'jf' Lim <jfs.world#gmail.com>
> > wrote:
> >> thanks, Unai for the follow-up!!! You know what, I just did a dump myself,
> >> and unbelievably, this is happening here as well. What gives? Initially, I
> >> was thinking that perhaps you had haproxy in tcp mode, but no, even in mode
> >> http, this thing happens as well. I'm happy, obviously - although like you,
> >> I dont exactly get how this could be happening.. Any idea, Willy?
> > btw, did some thinking :), and I thought i might have the answer. Would it
> > be safe to say (and i believe this is reasonable - I've been tracing down
> > the code, but havent gotten to this bit yet :( ) that haproxy really doesnt
> > do any reprocessing of the response body (only the headers), and so
> > essentially, the gzipped content is "passed through" without modification
> > (and the "Content-Encoding: gzip" header as well)? (I did see some mention
> > of chunking in the docs, btw, but dont believe that haproxy does rechunking)
> Willy, could you perhaps shed some light on this?
Yes. haproxy does not modify the data at all. Right now, it does not perform SSL nor compression. One day it will probably support SSL because even if that is expensive, there are reasons why it is often useful on a load balancer, but there are little chances it will support compression. All those CPU intensive processes should be installed in a scalable way on multiple machines, so that the load balancer does not become a bottleneck.
Currently, there are apache modules which perform compression (mod_gzip or mod_deflate, I don't remember which one is the more recent). You can very well install that on your servers and put haproxy in front of them.
Hoping this helps,
Willy Received on 2008/07/14 07:10
This archive was generated by hypermail 2.2.0 : 2008/07/14 07:15 CEST