Re: [squid-users] auth_param basic children question

On 2014-01-24 10:13, Scott Mayo wrote:
> On Thu, Jan 23, 2014 at 2:55 PM, Amos Jeffries <squid3_at_treenet.co.nz>
> 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
Received on Thu Jan 23 2014 - 22:12:06 MST