[squid-users] different delay pools for direct and parent

Hello everybody,

I posted this question a while ago and I havent found a solution since.
Maybe somebody can help me with this:

Due to our setup I have a problem using delay pools to equalize bandwith
usage.

All our clients connect to a debian-box running squid 2.4.6, which is
basically running as a child proxy (if this is the right term) with
DIRECT fallback.
All requests (even when noncacheables) are forwarded through a firewall
to a default parent, which is connected to a cheap ADSL line.
If the ADSL line or the parent is down, the child is allowed to fetch
the request directly using a second line. This line is not fast enough
to handle all the traffic from the proxy and some bandwith must be
reserved for other purposes (web, vpn).

Using delay pools and no-delay with the parent, this situation is under
control. When the parent goes down, the delay pools prevent an overload
nicely. When the parent is up again, back to unlimited.

But some users are overloading the big ADSL-Line as well with huge
downloads. Denying big files would be easy, but is out of the question.

I need to scale the bandwith which every user gets depending on a direct
or parent fetch. After weeks of reading through the docs and the
mailing-lists I doubt if this is possible.

IMHO the best solution would be to use different delay pools for parent
and direct connects. This would require an acl which matches only if the
request is fetched from a parent. AFAIK there is no such acl.

I could use delay pools on the parent, but only with an acl which
matches the reply-body-size to sort them in two class 1 - pools. AFAIK
there is no such acl.

A patch which turns the no-delay in to a scaling factor would be great.
I even took a look in the source-code, but without usable results.

I thought about switching to 2.5.5 to use an external acl with a helper
which checks if the parent is reachable, but this doesn't look like a
good solution.

Any help would be highly appreciated.

Best regards

Hendrik Voigtländer
Received on Mon Jul 26 2004 - 22:39:36 MDT