Re: Delay Pools

> Dear all,
>
> Using Squid 2.0, we want to apply delay pools since we don't have a high-bw
> link.
> > We have a group C subnet: 194.30.234.xxx.
> >
> > Aggregate pool (class1) works OK and straightforward for one host, a group
> > of hosts or the whole network.
> > But, what we need is to define some groups of IP addresses that will match
> > the users we want to categorize and assign different burstiness and of
> > course rate. I have completely understood the concept of the pools.
> > What I miss is how to define the different groups with ACL and how Squid
> > will recognise them.
> > I made an attempt with two groups in delay_class2 but it failed. Even only
> > one group failed in delay_class2.

Note that the current implementation can only have one class1 group, one
class2 group and one class3 group. It seems that multiple class1 and class2
groups might be something there is some demand for and I will consider making
a patch for this if I get the time. At present, the memory for the pools is
statically allocated (dynamic allocation would be less efficient) so multiple
class3 pools would probably be too memory-expensive, unless you someone really
needs them.

> > This is what I put in squid.conf:
> >
> > acl etsiot_host src xxx.xx.xxx.200-xxx.xx.xxx.210/255.255.255.255
> > delay_class2_access allow etsiot_host
> > delay_class2_aggregate_max 25000 (to be able to handle bursts)
> > delay_class2_individual_max 5000 -//-
> > delay_class2_aggregate_restore 100
> > delay_class2_individual_restore 500
> >
> > This didn't work. I also gave it a try with also defining a class 1 pool
> > for the same acl (class1+class2 with acl etsiot_host). In this case it
> > used the class 1 settings and ignored the class 2.

That is intended and documented - an access is only affected by the lowest
numbered delay pool which it is in.

> > One observation: In the cachemgr, for class 2 settings the current value
> > remains blank.

It's as if nothing were matching the ACL. Are you sure you don't have a
delay_class2_access deny all earlier in the config file, or have it always
so that the requests are already matched by delay_class1_access?

Maybe you should also add a delay_class1_access deny all to make sure that the
requests aren't being accidentally matched by class1.

> > Could you provide an example of how to define two different groups of IP
> > hosts with different settings?

This looks right to me. I'm not sure why it didn't work, but I'm not currently
using 2.0 and I'm quite busy for the next couple of weeks so I can't verify
that it works here. The original patch I did for 1.2.X definitely did.

> > Additionally, since we have two caches, can you help on how to define a
> > peer host (the other cache in each case), that should not get affected by
> > delay pools?

If you mean that a request satisfied by the peer host should not affect the
delay pool of the client requesting it (and should be transferred at full
speed), then simply add the "no-delay" tag to the end of the "neighbor" line
for that peer.

If you mean that cache misses for requests from the peer host should be
satisfied without delay, just modify the acl to exclude it, ie:
delay_class2_access allow !peerhost localnethost

If all of this still doesn't help, email me privately with more details
(and more of the relevant parts of your config) and I'll try to work it out.

David.
Received on Mon Oct 19 1998 - 21:39:16 MDT