Re: [squid-users] Delay_pool problem

 On Tue, 13 Dec 2011 14:12:48 +0100 (CET), FredB wrote:
> Hello,
>
> I wish to limit the bandwidth like this
>
> 1) Limit 64000 by user for objects more big than 30 ko
> 2) Limit global bandwidth to 1625000 - 13MB -
>
> I tried this configuration
>
> acl myusers src 10.0.0.0/8
> acl proto-pool port 80 81 21
>
> delay_pools 2
>
> delay_class 1 2
> delay_parameters 1 -1/-1 64000/30000
>
> delay_class 2 1
> delay_parameters 2 1625000/1625000
>
> delay_access 1 deny CONNECT
> delay_access 1 allow myusers
> delay_access 1 deny all
>
> delay_access 2 allow proto-pool
> delay_access 2 deny all
>
> squidclient
>
> Class: 2
>
> Aggregate:
> Disabled.
>
> Individual:
> Max: 30000

  --> maximum number of bytes which may be fetched by a client in one
 second.

> Restore: 64000

   --> maximum number of bytes added back into the "Max" buffer every
 second. Separate from how many bytes have been removed from the buffer
 during that second.

> Current: 52:30000 146:30000 168:30000 196:21312 172:30000 113:24270
> 86:30000 104:30000 120:30000 23:30000 157:30000 213:30000 77:30000
> 60:30000 124:30000 8:30000 21:-44294 80:30000 15:30000 20:30000
> 17:30000 3:30000 198:30000 30:25129 59:7438 32:30000 101:30000
 <snip>

  --> the list of currently active clients and how much free space their
 pool buffers have.

  Some such as client #52, have not used any traffic and have a full
 30000 bytes available.

  Some such as #59 have used some of the permitted amount but not all,
 and so have a under-30000 value. (7438 bytes available)

  Some such as #21, have somehow used more traffic than was in the
 buffer to begin with and have a negative value available. They will not
 be able to read anything until the 64K refill has raised their values
 back to positive again.
   (I _think_ this is related to uploads which may be wrongly accounted
 against the client traffic, but not delayed. However, there is an open
 bug about this negative value which still needs a deep investigation to
 figure out the details and fix.)

>
> Memory Used: 80928 bytes
>
> First problem, as you can see class 2 doesn't works - Aggregate
> Disabled -

 "Disabled" meaning no limit. AKA "-1/-1". Which is what you configured.

 The per-machine limit is set to 30000 *bytes* in any given second.
 Filling a bucket of 30KB with 64KB data will overflow and end up with
 only the smaller bucket amount available.

 For an example; if you poured a whole jug full of water into a small
 cup. Most of it spills out and the small cup amount is all you get left
 with to drink.

>
> And second problem
> When I tried with only class 2 -> no problem
> when I tried with only class 1 -> Surf is very very slow, even with a
> light page like google
>
> Have you any ideas ?

 The pool "2" (class 1) you configured is set to share a small 1.6MB/sec
 of traffic between all machines tagged with that pool. The ACL for that
 pool includes destination port 80 which just happens to be the port
 which web servers use. Now how many machines are there active in any
 given second?

 If you configured the 30KB/sec pool as a class 1, that would be even
 worse than 1.6MB/sec as a class 1.

 A class 2 pool with aggregate disabled appears to me to be the correct
 configuration for what you are aiming at. You just have to sort out what
 the correct limit settings need to be and which clients are pooled by
 the ACLs.

 Amos
Received on Wed Dec 14 2011 - 01:02:24 MST