On 10/02/11 00:05, Nick Cairncross wrote:
On 09/02/2011 09:34, "guest01"<guest01@xxxxxxxxx> 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
