Re: On the fly compression

>Robert Federle wrote:
>
>> The increased throughput and the reduced amount of traffic is
>> still an interesting feature as some people still have to pay for their
>> traffic.
>
>It may be an interesting feature. :-)
>
>First, examine a content of a cache. Typically, 70% of its content is
>GIF and JPG images and about 10% is textual files (HTML files, ftp
>directory listings, etc.).
>Is it worth implementing this feature?

As an Australian ISP, we get billed for our bandwith. If we put
compression on between the client and our proxy, the customers usage would
be far lower than actually downloaded, therefore we are losing out..

It would be really good for someone that didn't have to pay for bandwith,
or that had only a relatively small pipe..

One plan would be to have two caches; One simply a slave with a whopping
huge processor and heaps of ram but relatively small disk, and the master
to store all the pages on disk with a huge disk.

The Slave is the front-end proxy server, all the clients request from this.
The slave passes on requests to the master server, retrieves the result,
compresses it, and passes back down to the customer. This server may keep
up to an hour's worth of cached objects.

The Master server acts as a normal proxy server, caching to disk whatever
it can. Clients never talk directly to this server, infact the ACL's could
allow only the slave server to talk to it.

Also, perhaps there should be exclusions on what types of files are to be
compressed; .RAR, .Z, .GZ, .ZIP, .ARJ, .JPG, .MPG etc should be skipped by
default as they are already compressed pretty well and savings is
outweighed by the time spent compressing them.
Received on Wed Mar 17 1999 - 05:49:54 MST