Re: [squid-users] Tuning for very expensive bandwidth links

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 31 Mar 2011 02:23:05 +1300

On 31/03/11 01:38, Ed W wrote:
> Hi, Just investigating some tuning for squid for use with satellite
> links (which are relatively slow + bandwidth can be charged at $10-100/MB)
>
> I'm pondering having a dual proxy configuration with a proxy at both
> ends of the satellite link. A desired goal would be to force serving
> from local cache anything which hasn't actually changed (byte for byte)
> on the internet side.
>
> My thought was to investigate having the internet side proxy add etag
> headers to all content based on some quality hash function. Then have
> the (expensive) remote side proxy rewrite the request headers to always
> use If-None-Match? The idea is that the bandwidth is cheap on internet
> connected side, so it can refresh it's cache of the whole page, generate
> a new hash, but still return a "not modified" response if the end result
> is the same string of bytes. How much of that can I implement in Squid
> 3.x today..?

3.1.10+ will validate If-None-Match and ETag, but will not add them to
requests itself.

>
> Note, I realise this could lead to some side effects where the action of
> visiting the web page itself causes some other side effect, however, I
> think this is a manageable problem for this requirement?
>
> Thanks for any pointers to ideas or other products that might help?

ICAP or eCAP would be the way to go here for quick results. Making a
plugin to do the ETag generation and alterations before sending off.

You could also look at cutting bodies off 304 replies at the Internet
side to avoid the bandwidth expensive TCP_REFRESH_UNMODIFIED responses.

NP: if you want to go ahead and alter Squid code adding If-None-Match on
outbound requests is an open bug. As is proper ETag variant caching support.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.11
   Beta testers wanted for 3.2.0.5
Received on Wed Mar 30 2011 - 13:23:13 MDT

This archive was generated by hypermail 2.2.0 : Fri Apr 01 2011 - 12:00:02 MDT