On 2014-01-24 10:13, Scott Mayo wrote:
On Thu, Jan 23, 2014 at 2:55 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx>
wrote:
On 2014-01-24 04:04, Scott Mayo wrote:
Is there some standard that the auth_param basic children should be
set at when Squid is authenticating users?
Mine was set at 5. I have moved it up some when working with my
slowness issues. Slowness has pretty much gone away, but I am not
sure if it was that setting or some other things that I did.
I am just curious if the basic children should be close to the number
of users that I have or how I should try to figure that.
Not necessarily. There are a large number of factors involved; ratio
of
unique to repeat visitors (active user count), latency on the auth
verification, whether concurrency is involved, frequency of new
validation
lookups, TTL of the Squid cached helper results and size of that
cached set.
Between them these all balance performance vs responsiveness to
credential
change.
It does need to be high enough to service the number of validations
per-second that get past those performance tuning parameters.
Amos,
Would you have any suggestions? Here is a basic outline of my
school.
1. Around 400 devices.
2. Classes change each hour so probably within the first 5 minutes of
class, the students would be logging in. Most teacher machines would
already be logged in and just staying on.
3. Even though there are 400 devices, I would guess there are around
100 students logging in each hour within those first five minutes of
class.
I think that would be a typical scenario. Just looking for a
suggestion to start with.
I would suggest something like the following parameters:
# To make garbage collection run outside of regular class times
# so during the period when we expect peaks of login traffic GC
# does not get in the way.
# NP: the proxy should only be restarted at the time of evening you
want the
# GC cycle to occur. It will be run every 12hrs from last
start/restart.
authenticate_cache_garbage_interval 12 hour
# concurrency * children = 500 ... So that worst-case if the whole
school
# logs in at the same single second there is no overload on the
helpers.
auth_param basic children 5 startup=5 idle=1 concurrency=100
# How long to go between checking the credentials with the helper.
# With Basic auth this is the main means for reducing helper load, but
# does mean if you change a users password or remove an account it will
# take up to this long for the change to take effect in the proxy.
auth_param basic credentialsttl 3 hour
NP: if your helper does not support concurrency use the helper-mux.pl
which is bundled with recent Squid or downloaded from
ftp://ftp.squid-cache.org/pub/squid/contrib/helper-mux/. This is very
useful both in the higher speed concurrency offers and in reducing
helper virtual memory needs if your main Squid process has a large
memory footprint (eg. cache_mem or cache_dir data).
Amos
