Re: [squid-users] Compression

On 24 Aug 2001 14:19:27 +0200, Mike Kiernan wrote:
> Robert - thanks for the thorough explanation - the issues are much
> clearer now.
>
> > For more detail, and probably a better explanation, please see RFC 2616 :}.
>
> Your explanation was a lot more entertaining ;).
>
> > Overall, this looks really nice.
> > -- Brian
>
> I agree.
>
> > Does that about cover your questions? Any particular area I could
> > enlarge on for you?
>
> I'm wondering whether I could 'knock-up' a lightweight
> proxy - similar in form to the FilterProxy link that Vladislav
> sent out, but using pthreads/zlib directly to do 'content-encoding'
> [I don't think FilterProxy could handle 2000 simultaneous conns ;) ]
> ie. I would have:
>
> apache->squid-cache->compressionproxy->squid-delaypool->->browser

This would suffer from cpu load on the compressionproxy.

apache->compressionproxy->squid-cache->squid-delaypool->browser
is a better architecture. The squid-cache will get multiple entities
according to the Vary header, allowing the users browser capability to
determine which entity is served out.
note that this can collapse to
apache->mod_gzip->squid-cache->squid-delaypool->browser.

> Reason being the apache server is too stacked to do the mod_gzip
> work, and we'd really like the squid farm to do it - most likely
> before it hits the delaypool (which has to be in a non-cacheing
> squid as delaypools won't shape cached data) [ or would it make
> more sense to cache the content-encoded file??, ie. put the
> compressionproxy before the first squid-cache]

Yes. See above for logic.

Rob
Received on Fri Aug 24 2001 - 07:28:31 MDT