Вот неплохое описание алгоритма и концепций. Прошу прощения у автора -
я не помню источник.
======================================================================
Well, I think that delay pools is one of the most useful features of Squid,
addressed to manageable teams of users, so I will try to give a brief
explanation of how it works. I have not been involved in the development, so
David please correct me where I am wrong:
Delay pools are meant to provide a way of assigning tokens of bandwidth
allowance to Squid users. Pools are assigned on a host basis (IP), which
basically means that what you restrict is the WAN bandwidth pumped by Squid
for any individual host accessing the Net through it.
I am beginning from the most general case, which is the allowance for a
group of hosts (a block of IP addresses).
An individual host may be part of a group or be a group in itself.
In delay pools there are four basic parameters to be defined:
1) aggregate_max
2) aggregate_restore
and
3) individual_max
4) individual_restore
In order to understand the meaning of each parameter I will briefly explain
the concept behind delay pools:
For every host in one group there is one delay pool size descriptor
(individual_max) and one increment level (individual_restore) associated.
We can think delay pools as a bucket of tokens (bytes). The size of the
bucket (for one host) is individual_max bytes. At any given time, the bucket
can have at max that many tokens (bytes) accumulated. Before Squid fetches a
page for that host, it looks up the number of tokens (bytes) available at
the bucket. Let's call it the current bucket watermark. If there are enough
tokens in the bucket, Squid gets the tokens it needs, lowers the bucket
watermark accordingly and proceeds to reading a number of bytes from the
connection. If there are no tokens available, Squid is enforced to defer the
read, until some tokens (bytes) are available within the bucket. How is this
done? This is where the increment level value comes into play:
individual_restore defines the number of tokens (bytes) added to the current
bucket watermark level every second.
To further visualise it, think of a real bucket under a faucet: the bucket
can hold a certain amount of water (e.g. 1 litre). The faucet drops a
certain amount of water each second (for example 10 cl).
We start with the bucket filled of water, but as we start taking water off
the bucket with a glass, the available water goes down. If we want to keep a
steady watermark level we must take water with the same rate it is dropping
from the faucet. If we have a higher rate, the bucket will soon become
empty, and then we will have to wait until the faucet has dropped enough
water in the bucket again.
If we do not use any water for some time the water will overflow the bucket,
therefore the bucket will continue to have at most 1 litre of water for
immediate use.
At telecomm parlance, this is a variation of the leaky bucket algorithm (no
wonder why I used the bucket as an example)! It will (?)be used for
bandwidth policing in modern data networks (ATM for example).
How to configure the delay pools in Squid now:
At first decide what kind of grouping you need. If you want all your users
to have only one bucket then you go for delay_class1.
If you want to have separate buckets for each user then you must opt for
delay_class2 or class3 (depends on your network).
The Aggregate_* settings work almost the same way as the individual with one
distinction: in class 2 (this is what I use) and class3 the aggregate delay
pool is used only if no individual pool is defined.
IMHO I think that it would be more efficient if the aggregate delay pool
could provide tokens if an individual pool ran out of tokens at a certain
time. (This could be an additional measure to accommodate bursts for some
users).
If you decide that you need class2 then remember to put the statement
acl all src 0.0.0.0/0.0.0.0
delay_class1_access deny all
At present it is needed in order to allow class2/class3.
Assume that you want class2 delay pools. Then you need something like the
following:
acl hosts src xxx.xxx.xxx.a-xxx.xxx.xxx.b/255.255.255.255
delay_class2_access allow hosts
#delay_class2_aggregate_max 32000
#delay_class2_aggregate_restore 2000
delay_class2_individual_max 24000
delay_class2_individual_restore 1200
This defines a block of hosts with IP addresses in the Class C net from a to
b (but you can add also other individual hosts to the acl)
that will share the following pool settings:
Maximum pool size 24000 bytes
Increment level 1200 bytes
I don't use the aggregate settings because they do not have any effect when
individual pools are set.
The individual settings more or less let the host fetch "immediately" pages
that are slightly larger than 24000 bytes. If the host tries to fetch a
large page then Squid after the initial burst (~24KB) it will slow down to
the rate defined by the increment value defined by
"delay_class2_individual_restore" (i.e. 1200 bytes/sec).
If you do not want to allow for any burstiness in the delay pool then simply
define the max size of the pool equal to the restore size. (but this is
already documented).
Right now, you can have only one effective delay pool setting. This means
that you cannot set more than one group of users in the same class. I hope
that David will find the time to extend delay pools in order to handle more
than one type of host groups in one class. In my view this is necessary.
After using delay pools for some time now, I strongly think that it is a
powerful add-on to Squid. I think that if it is extended to handle multiple
groups (with different pool settings in each group) its value will be really
leveraged.
Cheers,
Evaghelos.
=========================================================================
Вариант для распечатки
OpenNET: Виртуальная конференция (Public)
on
05-Мрт-03, 00:20 (MSK)
