Re: [squid-users] Configuration Problems

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 31 May 2011 00:00:15 +1200

On 30/05/11 23:38, patric.glazar_at_arz.at wrote:
> Hello!
>
> We are using squid to solve bandwith regulation for our patchmanagment.
>
> What is our purpose:
> - we have a limited bandwith to our central PM-Server so each squid has a
> connection bandwith max 20 KB!
> therefore we are using delay pools class 1
> delay_pools 1
> delay_class 1 1
> delay_parameters 1 20000/20000 20000/20000
> delay_access 1 allow localnet
>
> - the clients in the internal Lan should get the download from squid as
> fast as possible,
> same request should be handelt as one - first fill the cache and then
> serve the download to the clients
> the cache should be cleaned after 1 year!
>
> hierarchy_stoplist cgi-bin ?
>
> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 525600
> refresh_pattern . 0 20% 4320
>
> range_offset_limit -1
> collapsed_forwarding on
>
> rightnow it looks like that all clients are sharing the 20 KB and therfore
> not one is getting the update

Yes. Assuming this is 2.7 (where collapsed forwarding works) one client
will be downloading and others waiting for the same URL will be sharing
the trickle as it arrives.

> - the cache is staing empty I donīt know why

If these are publicly accessible URL you can plug one of them into
redbot.org. It will tell you if there are any caching problems that will
hinder Squid.

Otherwise you will have to locate and figure out the headers (both
request and reply) manually.

Not being able to cache these objects could be part of the below problem...

> - a trace on the central PM Server shows that the squid Servers are
> donwloading a huge amount of data

Check what that is. You can expect all clients to parallel download many
objects. But they should still be bandwidth limited by Squid within the
delay pool limits.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.12
   Beta testers wanted for 3.2.0.7 and 3.1.12.1
Received on Mon May 30 2011 - 12:01:01 MDT

This archive was generated by hypermail 2.2.0 : Mon May 30 2011 - 12:00:05 MDT