Такая возможность появилась в squid 2.0 и называется delay
pools. Прежде всего проверьте, была ли включена эта
возможность на этапе компиляции squid ключом утилиты
configure --enable-delay-pools.
В squid.conf нужно будет прописать нечто вроде:
acl comp src 192.168.10.15/255.255.255.255
delay_class1_access allow comp
delay_class1_aggregate_max 8000
delay_class1_aggregate_restore 8000i
Заметьте, что объекты из кэша не замедляются.
Поищите в архивах squid переписку по этому поводу, а
точнее, http://www.cineca.it/proxy/search/html/9812/139.html.
Это письмо автора с подробными разъяснениями. По слухам,
реализация delay pools для class1 работает плохо, поэтому
уменьшать скорость работы нужно по class2, а для class1
сделать следующее:
delay_class1_access deny all
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. И еще одна добавка от автора delay pools Subject:
Re: DELAY_POOLS: How to setup Resent-Date: Wed, 11 Nov 1998
18:27:05 -0800 (PST) Resent-From:
[email protected]
Date: Thu, 12 Nov 1998 09:29:04 +0800 From: David Luyer
<
[email protected]> To: Evaghelos Tsiotsios
<
[email protected]> CC:
[email protected],
[email protected] Thanks to Evaghelos Tsiotsios for his
description of delay pools. A few clarifying comments are
below; > 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. This assumption
(and related comments later) is incorrect. (Or if it is
correct it is a coding error.) The aggregate and individual
totals both act to limit the traffic, if either is empty then
the request is delayed. For example, I run approx 64kbps peak
rate (with small 'bucket size') on one of the delay_class2
pools and then give each user in it approx 8kbps (with large
'bucket size'). The large bucket size on individual users
lets each user get a web page "instantly" but if they start
downloading a large file it is slow. The small bucket size on
the aggregate means that the 64kbps is the limit of bandwidth
use (modulo overheads) for these users. Also, I didn't notice
any mention of the 'no-delay' tag you can put on neighbors -
this will prevent traffic fetched from that peer from being
'taken out of the bucket'; for example if you have a fast,
"free traffic" ATM network to local universities but anything
further away costs money, and you peer caches with local
universities, you can put the 'no-delay' tag on these peers
cache_host lines. Regarding class2/3 delay pools: It could
take some time before I'm able to do any work on multiple
delay pools of a given class. How I think it should work is
this (sorry, sparse documentation on this, but I hope enough
to show anyone whose interested and understands the current
system what it means): delay_pools 3 # 3 delay pools
delay_class 1 1 # pool 1 is class 1 delay_class 2 1 # pool 2
is class 1 delay_class 3 3 # pool 3 is class 3 delay_access 1
allow staff delay_access 1 deny all delay_access 2 allow
students delay_access 2 deny all delay_access 3 allow college
delay_access 3 deny all delay_parameters 1 640000/640000
delay_parameters 2 64000/64000 delay_parameters 3 64000/64000
32000/64000 6400/32000 # ttl_rest/ttl_max net_rest/net_max
ind_rest/ind_max The acls and delay pool data could then be
dynamically allocated. Maybe once this was done delay pools
could be put into squid by default as the cost of disabled
delay pools would be very close to zero (simply a few checks
if delay_pools number was 0). David.
