Re: [squid-users] kerberos authentication - performance tuning

On 10/02/11 00:05, Nick Cairncross wrote:
> On 09/02/2011 09:34, "guest01"<guest01_at_gmail.com> wrote:
>
>> Hi,
>>
>> We are currently using Squid 3.1.10 on RHEL5.5 and Kerberos
>> authentication for most of our clients (authorization with an icap
>> server). At the moment, we are serving approx 8000 users with two
>> servers. Unfortunately, we have performance troubles with our Kerberos
>> authentication. Load values are way tooooo high ...
>>
>> 10:19:58 up 16:14, 2 users, load average: 23.03, 32.37, 25.01
>> 10:19:59 up 15:37, 2 users, load average: 58.97, 57.92, 47.73
>>
>> Peak values have been>70 for the 5min interval. At the moment, there
>> are approx 400 hits/second (200 per server). We already disabled
>> caching on harddisk. Avg service time for Kerberos is up to 2500ms
>> (which is quite long).
>>
>> Our kerberos configuration looks pretty simple:
>> #KERBEROS
>> auth_param negotiate program
>> /opt/squid/libexec/negotiate_kerberos_auth -s HTTP/fqdn -r
>> auth_param negotiate children 30
>> auth_param negotiate keep_alive on
>>
>> Is there anyway for further caching or something like that?
>>
>> For testing purposes, we authenticated a certain subnet by IP and load
>> values decreased to<1. (Unfortunately, this is not possible because
>> every user gets a policy assigned by its username)
>>
>> Any ideas anyone? Are there any kerberos related benchmarks available
>> (could not find any), maybe this issue is not a problem, just a
>> limitation and we have to add more servers?
>>
>> Thanks!
>>
>> best regards
>> Peter
>
> Peter,
>
> I have pretty much the same setup as you - just 3.1.8, though only 700
> users.
>
> Have you disabled the replay cache:
> http://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos
> But beware of a memory leak (depending on your libs of course):
> http://squid-web-proxy-cache.1019090.n4.nabble.com/Intermittent-SquidKerbAu
> th-Cannot-allocate-memory-td3179036.html. I have a call outstanding with
> RH at the moment.
>
> Are your rules repeating requesting authentication unnecessarily when it's
> already been done? Amos was very helpful when advising on this (search for
> the post..)
>

Along with connection persistence. The closest thing to caching Kerberos
(and NTLM) have in Squid is being linked to the connection for use
across multiple requests. There is no TTL on the auth itself, so the
longer the connections can stay open the less backend validation.

> 8000 users.. Only 30 helpers? What does cachemgr say about used negotiate
> helper stats, timings/sec etc.
> Is your krb5.conf using the nearest kdc in it's own site etc?
>
> Some load testers out there incorporate Kerberos load testing.
>
> Just my thoughts..
>
> Nick
>

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.11
   Beta testers wanted for 3.2.0.4