Re: [squid-users] Delay pools bucket refill

From: Johannes Buchner <buchner.johannes_at_gmx.at>
Date: Fri, 26 Dec 2008 18:38:16 +0100

Hi all!

Another note:
The delay_parameters can only take 31 bits (signed int) as argument for
the bucket size, so .../2147483647 is the maximum you will get.
Maybe this should be noted in the documentation?

Regards,
Johannes

On Fri, 26 Dec 2008 18:14:40 +0100
Johannes Buchner <buchner.johannes_at_gmx.at> wrote:

> Hi all!
>
> I tested delay pools to answer my question using this configuration:
>
> 1> acl night time 1:00-7:00
> 2> acl testtime time 17:46-17:48
> 3> delay_pools 2
> 4> delay_class 1 1 # full bandwith
> 5> delay_class 2 2 # limited per user
> 6> delay_parameters 1 -1/-1
> 7> delay_parameters 2 -1/-1 1000/1000000
> 8> delay_access 1 allow night testtime all
> 9> delay_access 2 allow !night !testtime all
> A> delay_initial_bucket_level 100
>
> - Download a file of 51 MB at 17:44
> - first 1 MB is full speed (from pool 2, line 7). full speed is
> 400KB/s here.
> - then the speed is 1000B/s (from pool 2, line 7).
> - at 17:46 the download continues to go with 1000B/s. The pool is not
> switched.
> - I am restarting the transfer: full speed for the whole
> transfer. If it takes longer than the time-acl is limited to, the full
> speed is still given.
>
> Conclusion: The pools are used connectionwise, and do not switch over
> when the time-acl becomes active. In other words, the delay_pools are
> chosen by looking at the acls only at the beginning of the transfer. I
> assume this is a wise design decision, as continueous checks would
> decrease performance.
>
> It means however, that one can start a huge transfer in the 'night'
> and block the traffic during the day. The effect can be minimized by
> using request_body_max_size.
>
> To my original question:
> If you drained your bucket at the end of the acl time, how full is it
> at the beginning of the acl time the next time. Is it full, is it
> delay_initial_bucket_level, is it stored from the last fill state,
> does it refill in the time the acl is inactive?
>
> My test showed that it in fact refills during the time the acl is
> inactive. If the acl is inactive 3 minutes (if testtime is 3 minutes
> long), the bucket should be filled with 1000*3*60 Bytes, and my tests
> confirmed this.
>
> I assume the calculation behind it is invoked on a new connection and
> just looks at the time passed since the last transfer and calculates
> the new fill state from the timespan. Calculating in the time-acls
> would be too complex, as the acls can be configured in quite complex
> ways.
>
> Best regards,
> Johannes
>
> On Wed, 24 Dec 2008 15:47:12 +1300
> Amos Jeffries <squid3_at_treenet.co.nz> wrote:
>
> > Johannes Buchner wrote:
> > > Hi!
> > >
> > > I have a question about delay_pools: If I make a time-based acl
> > > with a delay-pool, does it refill in the time the acl is inactive
> > > or is the amount "stopped" and continued when the acl starts
> > > again?
> >
> > Pools refill at the constant rate unless the are full or
> > reconfigured. Client usage is not taken into consideration on the
> > filling, only on the emptying.
> >
> > >
> > > Like, if I have a pool acl going from 9:00 till 20:00 with a size
> > > of 3GB and a rate of 1200 B/s, and a client runs low on the bucket
> > > at 20:00. What will he be able to download at 9:00 the next day?
> > >
> > > Also, if I would define one bucket for 9:00 till 20:00 and another
> > > one for 20:00 till 9:00 of different sizes and rates, would they
> > > share their amount? Probably not I guess.
> >
> > Correct. No. They are different pools.
> >
> > Amos
> > --
> > Please be using
> > Current Stable Squid 2.7.STABLE5 or 3.0.STABLE11
> > Current Beta Squid 3.1.0.3
>
>
> --
> Emails können geändert, gefälscht und eingesehen werden. Signiere oder
> verschüssele deine Mails mit GPG.
> http://web.student.tuwien.ac.at/~e0625457/pgp.html
>

-- 
Emails können geändert, gefälscht und eingesehen werden. Signiere oder
verschüssele deine Mails mit GPG.
http://web.student.tuwien.ac.at/~e0625457/pgp.html

Received on Fri Dec 26 2008 - 17:38:36 MST

This archive was generated by hypermail 2.2.0 : Sat Dec 27 2008 - 12:00:01 MST