Re: [squid-users] Delay Pools advice?

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 09 Dec 2009 14:25:29 +1300

On Tue, 08 Dec 2009 17:13:56 +0200, Roland Roland
<R_O_L_A_N_D_at_hotmail.com>
wrote:
> Hello,
>
>
> i've set up squid about 2 month ago with poorly configured settings just

> to set things going ( i admit it wasnt the right thing to do thoguh time

> were of the essence )
> at the moment i decided that it's about time to take a look at each rule

> i've made and fix it to the best i could. so i'm sending this email
> hoping someone would show any mistake i might have done :
>
>
> I. Info:
>
> 1. Our working hours are from 8 am to 6 pm
> 2. One ISP link that's dedicated for squid/browsing has a 2 mb shared
> bandwidth with 8 GB of quota
>

Clarity please: 2 mb ==
 * 2 mb (milli bits?)
 * 2 Mb (mega bits)
 * 2 MB (mega bytes)?

I assume you omitted the 'ps' (per-second) units as well.

being specific of the "2 mb" makes the difference between whether we tell
you the config for a 256KiBps or 2MiBps data cap.

>
> II. Required:
> 1. spread the bandwidth equally among users at all times (if there;s 2
> ppl online than they should share the 2 mb hence having a faster
> connection than usual (Not Working)
> 2. Opening websites should have a little burst though downloading files
> should be shaped
>
> III. What i've done:
>
>
##################################################################################working
>
> Hours
> acl work_hours time MTWHF 08:00-20:00

NP: excludes saturday/sunday. You didn't mention days that in your policy
specs only times.

>
##################################################################################subnet
>
> that's shaped
> acl limitedto8 src 192.168.75.0/255.255.255.0

acl limitedto8 src 192.168.75.0/24

>
##################################################################################Site's
>
> that should have a very low bandwidth
> acl slowsites url_regex -i "/etc/squid/slowsites.txt"
>
##################################################################################Destination
>
> that should not be shaped
> acl mySubnet dstdom_regex 192.168.75

You want the URLs containing raw-IPs http://192.168.75.*/ and
http://*.192.168.75/ to be available?

Or only the internal destinations?

  acl mySubnet dst 192.168.75.0/24

>
##################################################################################Destinations
>
> that should never be shaped.
> acl NoShape url_regex "/etc/squid/NoShape.txt"

Hmm, surely this is full of domain names and IPs right?

With a little auditing of the file contents you should be able to convert
that to the faster:
  acl noShape dstdomain "/etc/squid/NoShape.txt"

>
##################################################################################For
>
> users would temporary would be allowed to gain higher bandwidth
> acl download src 192.168.75.138
>
>
>
> delay_pools 2
> delay_class 1 2
> delay_parameters 1 -1/-1 -1/-1
> delay_access 1 allow NoShape download

NP: pool 1 is not useful.
 * it wastes CPU cycles trying to account for all traffic going through
the unlimited users.
 * users which are excluded from the pool #2 below will not be limited
anyway.
 * you can safely drop pool #1

>
###################################################################################limiting
>
> every user in the subnet 192.168.75.0/24 and allowing NoShape and
> download acl to use the bandwidth freely
> delay_access 2 allow limitedto8 !NoShape !download
> delay_access 2 deny all
>
###################################################################################Bandwidth
>
> for this delay pool is 512 KB where each user can download at a speed of

> 10 KB
> delay_parameters 2 512000/512000 -1/-1 10000/512000

NP: the above is a 512 KByte total bandwidth cap (base 1000).

For 512 KiB (base 1024) affecting total and users that should be:
  delay_class 2 2
  delay_parameters 2 524288/524288 10240/10240

To meet your spec of a "2 mb" pipe that would be:

 delay_class 2 1

(2 Mbps) delay_parameters 2 262144/262144
or
(2 MBps) delay_parameters 2 2097152/2097152

with the same delay_access.

Amos
Received on Wed Dec 09 2009 - 01:25:36 MST

This archive was generated by hypermail 2.2.0 : Wed Dec 09 2009 - 12:00:01 MST