Re: [squid-users] Delay_pool problem

Thanks a lot I will try that

----- Mail original -----
> De: "Amos Jeffries" <squid3_at_treenet.co.nz>
> À: squid-users_at_squid-cache.org
> Envoyé: Mercredi 14 Décembre 2011 01:02:21
> Objet: 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 - 08:41:15 MST