Re: HTTP serving compressed content (was Re: Perl "competitor" Curl raises $52M)

From: Bill Stoddard (bill@wstoddard.com)
Date: Thu Mar 15 2001 - 17:40:51 PST


Josh,
Did you do any testing of compressing bytes to be sent out over an SSL
connection (compress then encrypt)? I have a hunch (and that is all it is)
that compressing byte streams about to be sent out over an SSL link would
help response times for clients dialed in to the net. Just curious...

Bill

> I'd have to disagree here. I worked on both sides of
> the puzzle here, first on Netscape Proxy server and then
> on IE. The main thing is that hosting servers tend
> to be resource bottleneck, either CPU, disk, DB access etc..
> Adding compressing significantly adds work to the system.
>
> On the proxy server, we tested options to compress
> content on the fly and in the cache. Most of our
> customers had proxies deployed at the firewall or
> edge of the network, which meant that all traffic
> was driven through it. As a result, these boxes
> were extremely busy and customers wouldnt enable
> the feature.
>
> Outside of proxies, IIS (or apache) were busy running
> CGI, ASP, or now PHP. Adding compression actually
> slowed things down, since the servers were much busier.
>
> Even though its clear that from a mathematical perspective,
> the overall system may have been faster, the user perception
> of speed is much different. While the compression was
> a good thing for the internet as a whole system, site operators
> were concerened primarily with the users perception of site speed.
> Our studies in IE showed that the main factor was latency,
> not bandwidth, and compression really only helps bandwidth.
>
> Further, as pages got more and more complicated with javascript,
> CSS, the rendering phase of the page display became a bigger
> and bigger bottleneck (on the client side). Adding a decompress
> phase just slowed things down in terms of latency, eg time until
> the browser could initially draw the page, or time until the user
> could click a link.
> People didnt seem to mind that it took longer for the page to
> completely finish loading , which compression would have definitely
> helped, or for images to trickle in , which it wouldnt help anyway.
>
>
> >-----Original Message-----
> >From: Andy Armstrong [mailto:andy@tagish.com]
> >Sent: Thursday, March 15, 2001 16:21
> >To: Damien Morton
> >Cc: 'fork@xent.com'
> >Subject: Re: HTTP serving compressed content (was Re: Perl "competitor"
> >Curl raises $52M)
> >
> >
> >Damien Morton wrote:
> >[snip]
> >> > mod_gzip works pretty transparently with Apache.
> >>
> >> IIS caches the compressed content, how does mod_gzip work?
> >
> >It compresses on the fly every time, but doesn't seem to slow things
> >down too much.
> >
> >--
> >Andy Armstrong, Tagish
> >



This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:14:16 PDT