Thanks a lot I will try that ----- Mail original ----- > De: "Amos Jeffries" <squid3@xxxxxxxxxxxxx> > À: squid-users@xxxxxxxxxxxxxxx > Envoyé: Mercredi 14 Décembre 2011 01:02:21 > Objet: Re: 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 >
