Re: delay pools (fwd)

From: David Luyer <luyer@dont-contact.us>
Date: Mon, 22 Feb 1999 23:29:25 +0800

> "DL" == David Luyer writes:
>
> >> do the delay pools limit the bandwidth of squid->client transfers,
> >> or the squid<->[parent_or_direct_access] ?
>
> DL> They limit the speed an object is transferred (both to the client
> DL> and into the cache). The limit is applied to direct access and
> DL> to selected peers, by default to all peers but it is possible to
> DL> use the 'no-delay' tag to specify that some peers should not be
> DL> subjected to the limit.
>
> thanks. i.e., suppose that we have some config like
>
> acl vsu-clients src 62.76.168.128/25 62.76.169.128/25
> delay_class1_access deny all
> delay_class2_access allow vsu-clients
> delay_class2_aggregate_max 16384
> delay_class2_aggregate_restore 8192
> delay_class2_individual_max 4096
> delay_class2_individual_restore 2048
>
> does this mean that any client listed in the acl `vsu-clients' will be
> limited by 2Kb/s (with the total bandwidth no more than 8Kb/s)? i.e.,

Yes, except for the problem with IP overlap I mention below, and make
sure that you are aware that this is kilo-BYTES/second, whereas most
people think in kbps - kilo-BITS/second. So you're talking 16kbps and
64kbps.

> 62.76.169.129 <---(1)---> squid <---(2)---> www
>
> both the internal channel (1) and external channel (2) for client
> 62.76.169.129 will be used no more than with 2Kb/s?

Sorry, I got this wrong. The 'internal channel' isn't directly limited,
it is only limited as a result of the 'external channel' being limited.
I didn't quite get what you meant.

Also, your ACL includes hosts on 2 subnets into the same class2 pool.
This is not good. It means, eg, host 62.76.168.128 and host 62.76.169.128
share the same 2Kb/s allocation. The best current solution to this is to
get my squid-diff-9.gz (http://typhaon.ucs.uwa.edu.au/squid-diff-9.gz) and
apply it to the lastest squid-2.1.X. This should be incorporated properly
into a later version of squid-2.2, however it isn't quite right in the current
squid-2.2 and I would not recommend using that version. With this patch
you can define multiple class 2 delay pools (the syntax has completely
changed, but there are much better examples in the config file so it should
be quite easy to understand). Alternatively, with the version which you
have, you could use a class3 delay pool.

(or, it could be that your example IPs were on separate 8-bit networks
when your real ones aren't, in which case this doesn't apply)

> one thing which is desirable: the internal channel (1) is often faster
> than the external one. so, we'd like to limit the channel (2), but
> have much more liberal policy on the internal channel. i.e., if
> client's request hits the already chached object, it should be
> transfered to client at a high speed (without limits or with
> separately-specifyable limits). but if the requested object should be
> transfered via the external channel, we'd like to have a `delay pool'.
>
> is this possible?

Oh, I should've been more clear. Already cached data is always delivered
at the full speed, and has no effect on delay pools. I guess, now I
reconsider what you meant, that I should've said that the squid->client
transfer is not restricted.

> >> is it possible to limit the squid<->[parent_or_direct_access]
> >> bandwidth (i.e., limit the external channel) for a given class of
> >> squid clients?
>
> DL> Yes. Read the config file. Personally I recommend squid-2.1
> DL> with the patch at http://typhaon.ucs.uwa.edu.au/squid-diff-9.gz ,
> DL> however and squid-2.1 should do it fine. It sounds like you
> DL> simply want a 'class 1 pool' (a single aggregate limit).
>
> the `class 1 pool' sets the single global policy which is the same for
> all transfers. are there some means to specify different bandwidth (of
> external channels) for different clients?

That's for class 2 and class 3. As you seem to have discovered.
If you want multiple pools, which I think you would benefit from
(see above), you need my squid-diff-9.gz against 2.1.

David.
Received on Mon Feb 22 1999 - 08:57:06 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:44:38 MST