Mon, 09 Aug 2004 08:57:38 -0700 tarihinde, MonkeyOmen dedi ki:
> I'm working on a Squid proxy where the intent is to conserve bandwidth
> by slowing down heavy users.
>
> I'd appreciate some help with the squid.conf syntax as I'm a relative
> novice with Squid.
>
> First, our network and users:
> - Everyone on our network has an address in the 192.168.100.x range
> - The total bandwidth available is 1024 kbps down and 256 up
> - I want everyone in the 192.168.100.10-249 range to be limited
> - I want everyone in the 192.168.100.250-254 range to NOT be limited
> - I'm running version 2.4.STABLE6 on a Debian Linux system (Woody)
>
>
> Here's what I've got:
>
> # define my two groups by IP address
> acl usergroup1 src 192.168.100.250-192.168.100.254/32
> acl usergroup2 src 192.168.100.10-192.168.100.249/32
>
> # define one class 2 pool
> delay_pools 1
> delay_class 1 2
>
> # no delays for usergroup1
> # usergroup2 follows the rules of pool 1
> delay_access 1 allow usergroup2 !usergroup1
> delay_access 1 deny all
I would suggest removal of the "!usergroup1" because it has no effect,
other than unnecessary burden on CPU. For the purposes of this setup you
don't even need to define the "acl usergroup1". (192.168.100.1-9 is
treated the same way as usergroup1 anyway.)
> # We have 1024 kbps / 8 = 128 kbytes/sec downlink bandwidth # # Everyone
> in usergroup2 has access to the full bandwidth until # his 128 kbyte
> bucket is empty, then it refills at 4 kbyte/sec # This ought to allow
> fast page loads every 30 seconds or so, # while throtting back large
> downloads. I think.
>
> delay_parameters 1 -1/-1 4000/128000
This is the speculative part. I don't know how many desktops you have, but
being too stingy here might stiffle your link, and you might observe that
everybody is complaining about the sluggishness of internet, while the
link is only utilized 30%. Deferring the issues with aggregate limits
(-1/-1) for now, let's concentrate on the individual limits (4000/128000).
Anybody will have unlimited (-1) bandwidth until their bucket (credit) is
exhausted and then fall down to 4K/s for the rest of the page. This is too
restrictive. There are very legitimate, no graphics, all text pages that
can exceed 512K easily. There are images and full featured pages
(including JS and applets) that can approach to 1 MB. If your aim is to
curb download freaks, while being transparent to casual surfers, then I
would suggest generous bucket size such as 1MB, and a speed limit that is
sufficient enough to refill the bucket in reasonable time while
restrictive enough to curb download freaks and protect your bandwidth. My
main criteria is this: A casual surfer, no matter how active he is and no
matter how bloated sites he visit, should rarely be throttled down, while
a downloader should hit the throttler right ahead. The main characteristic
of the former is repeated bursts of traffic, with some delay between
bursts. The characteristic of the latter is a continuous streaming of
traffic. No matter how large a bucket you allocate, the downloader will
quickly deplete his bucket and start begging for the crumbs. In short, I
would suggest 512K to 2M bucket size, and such a speed limit that when
aggregated, it would sum up to approximately twice of your current link
capacity. I.e. 2048/N where N is number of users.
> # everyone's bucket starts out full
> delay_initial_bucket_level 100
You can safely leave it to default of 50% as the bucket will fill up in a
second anyway. Specifying it (anything from 0 to all the way up to 100)
would cause no harm though. The benefit of leaving it to default is, you
would have one less parameter to distract your focus.
> Will this work as I intend?
>
>
> Is there a way to *really* throttle back a user based on file type or
> size requested? For example, if one of the usergroup2 guys starts to
> download a .zip file or something over 2 megabytes, can I throw him into
> a second delay_pool with different parameters just for the duration of
> that download? How would I do that?
For fast links there is a possibility that processing delays in delay
pools could hinder the link capacity. I had such an issue in the past. So
I would particularly suggest the latest affordable squid version (sarge),
and a first trial with very generous limits, and see the line utilization.
And then disable delay pools for a few days and again note the line
utilization. I am curious of the results, and I would appreciate your
feedback.
--
Abdullah | aramazan@ |
Ramazanoglu | myrealbox |
________________| D-O-T cöm |
|
Similar Threads
Linear Mode
