On Mon, Jul 14, 2008 at 1:10 PM, Willy Tarreau <w#1wt.eu> wrote:
> Hi JF,
> > > 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
> > >> 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
> > >> http, this thing happens as well. I'm happy, obviously - although like
> > >> 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
> > > be safe to say (and i believe this is reasonable - I've been tracing
> > > the code, but havent gotten to this bit yet :( ) that haproxy really
> > > do any reprocessing of the response body (only the headers), and so
> > > essentially, the gzipped content is "passed through" without
> > > (and the "Content-Encoding: gzip" header as well)? (I did see some
> > > of chunking in the docs, btw, but dont believe that haproxy does
> > >
> > Willy, could you perhaps shed some light on this?
> Yes. haproxy does not modify the data at all. Right now, it does not
> 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
> but there are little chances it will support compression. All those CPU
> intensive processes should be installed in a scalable way on multiple
> so that the load balancer does not become a bottleneck.
yes, you're right! that is truly the only reliable way to scale... :)
> 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,
yeah, it does.
-- In the meantime, here is your PSA: "It's so hard to write a graphics driver that open-sourcing it would not help." -- Andrew Fear, Software Product Manager, NVIDIA Corporation http://kerneltrap.org/node/7228Received on 2008/07/14 07:15
This archive was generated by hypermail 2.2.0 : 2008/07/14 07:30 CEST