mikewest09 wrote:
Hi All,
Thanks Amos and Chris for your time and help, I have few more questions so I
will appreciate it so much if you can please take a look at them
A. As a start to avoid confusion here are some facts regarding our server
and users
- All of our users connect to our proxy (SQUID) through an application. This
desktop application contains built-in (User name / password) for
authenticating each of our users to use our SQUID proxy (installed on our
server) AND also contains the IP of our server (which have SQUId installed
on it)
- Our users come from many different locations around the world and many of
them (most of them actually) don't have 'static Ip's so I can't setup
specific range of IP's
- We have more than 100,000 registered users (beside those whom will
register in the future) from different locations around the world. Of course
not all of them will login together at a specific moment, but many of them
can be on the server at the same moment and this was one of the major
reasons why we need to regulate SQUID traffic usage
B. Even though I have read info about classes 1,2,3,4 I can't understand up
to this moment which will be better for us? So based on the info I just
provided in A, do you have any recommendations especially when taking in
consideration the amount of users we have
Depends on what you consider the most stable detail. username or IP.
Given that you said most users are on dynamic IPs I'd go with username.
class 4. With all fields except the user one set to -1/-1
C. delay_parameters 1 -1/-1 1310720/15728640
isn't -1/-1 is for unlimited access? i mean can you please explain this
rule so I can understand its limitations?
"unlimited" here means only "unlimited by Squid" the external network
settings still apply.
If you think of it like a geographic hierarchy it makes more sense.
class 1: for limiting the entire network HTTP bandwidth.
class 2: for limiting individual machines
+ maybe entire network.
class 3: for limiting individual machines
+ subgroups of machines
+ maybe entire network.
class 4: for limiting on login usernames
+ maybe individual machines
+ maybe subgroups of machines
+ maybe entire network.
class 5: for advanced custom controls.
Lets take a small office LAN as the theoretical situation:
With class 1 the office can have a 10Mbps pipe and a policy of
allowing only 2Mbps for web browsing traffic "aggregate" (8Mbps
dedicated to the phones or external services etc).
Effects: any single office PC can reach 2Mbps alone, or four can each
simultaneously do 256Kbps. The 2Mbps is parceled equally between all.
With class 2 they can take their 2Mbps traffic policy "aggregate" and
add a condition that no one office machine can use more than 256Kbps at
once "individual".
Effects: running 3 or less PC at once will leave some hundreds of Kbpps
"wasted" empty, even as each PC can runs at their peak 256Kbps. Five or
more PCs will start to degrade each others experience as the 2Mbps is
parceled equally between all at 200Kbps each.
With class 3 they can have two offices next to each other who are
allowed 1Mbps each. So one machine in office A can use 1Mbps by itself
"individual" while two others in office B are at 500Kbps sharing the
other 1Mbps "network". The total bandwidth stays within the overall pipe
limit "aggregate".
For you with class 2 I set non-individual caps as unlimited. Which means
that Squid trusts the underlying network to get the pipe limits and
sharing right. Squid will try to use as much bandwidth as needed to
supply the current clients.
Looks liek class 4 might be better for you, in which case the aggregate,
network, and individual fields would be unlimited and only the username
one set to the 10Mbps/15MB values.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
Current Beta Squid 3.1.0.15
