Re: Maximum connections for squid-users

On Thu, 5 Jun 1997, Cord Beermann wrote:
>A way to specify and enforce resource limits. e.g.:
>
> 1) prevent a class of users from using too much bandwidth.
> 2) limit number of simultaneous FTP requests.
> 3) Prioritize requests based on various parameters including
> "un-hit rate."

Well, there is the UCS modification of squid, avaliable in /pub/squid on
ftp.uwa.edu.au as something like diff-1.1.10-1.1.10.ucs. This does
various things with bandwidth restriction for a couple of different user
classes, I'm sure I've mentioned it a couple of times before. We've had
it running ages with no problems; I don't think it'll ever make the main
squid source since it's not quite "perfect" - it makes the assumption that
the last 16 bits can be used to represent the host, and the first 8 of
those can be used to represent the subnet. It would be trivial to tailor
it to your needs, tho.

Currently implemented (these can be set near-infinite if unwanted):

  two acls, to put host(s) and url(s) in delay pool 1 or 2

  delay pool 1:

     limited on aggregate only.

  delay pool 2:

     limited on aggregate, per-subnet and per-host by seperate controls.
     seperate aggregate pool to delay pool 1.

Direct fetches are not slowed. A neighbour or parent can be specified as
being delay or "no-delay"; or the same host can be used as both neighbour
or parent (I use a virtual interface to distinguish here) using delay on
one and no-delay on the other. [I'm acutally running the hosts in delay
pool 2 off two parents dependant on administrative reasons here.]

The limits are in the form of a per-second usage allowance being put into
a pool capped at a limit, all configurable by squid.conf of course.

For example, here:

# TAG: cache_host
[...]
# options: proxy-only
[...]
# no-delay
[...]
# use 'no-delay' to prevent access to this neighbor
# infuencing the delay pools.
[list of local peers and multicast groups, multicast-responders all as
proxy-only no-delay - bandwidth on local ATM network to burn]
[list of parents including local peer's virtual interface and remote
parent as no-query default, which parent controlled by cache_host_acls]

inside_firewall [list of local domains]

local_domain [same list]

# TAG: delay_access
#
# Set this for hosts to be in the unified and per-host delay pools.
delay_access allow students
delay_access allow nonstudents
delay_access deny all

# TAG: delay_child_access
#
# Set this for hosts to use the child delay pool. This removes
# them from the unified or per-host delay pools if they were in them.
delay_child_access allow cygnus
delay_child_access deny all

# TAG: delay_max
#
# The maximum bytes in the unified delay pool.
delay_max 131072

# TAG: delay_restore
#
# The bytes per second added to the unified delay pool.
delay_restore 6144

# TAG: delay_host_max
#
# The maximum bytes per host in the per-host delay pool.
delay_host_max 8192

# TAG: delay_host_restore
#
# The bytes per second added to each host in the unified delay pool.
delay_host_restore 384

# TAG: delay_net_max
#
# The maximum bytes per net in the per-net delay pool.
delay_net_max 24576

# TAG: delay_net_restore
#
# The bytes per second added to each net in the unified delay pool.
delay_net_restore 1152

# TAG: delay_child_max
#
# The maximum bytes in the child delay pool.
delay_child_max 1638400

# TAG: delay_child_restore
#
# The bytes per second added to the child delay pool.
delay_child_restore 8192

This delay code can be useful for various things - administratively
limiting usage, or limiting a modem client to 28k (or an ISDN client to
64k and all their modem IPs to 28k each) so that your main link isn't
flooded by gets for slow clients, and so on...

David.
Received on Thu Jun 05 1997 - 03:44:37 MDT