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

I think nobody has done any performance test with Kerberos authentication.
As you may have seen I provided a patch to polygraph to do exactly that.
Unfortunately I don't have the HW to run the test myself.

Markus

"guest01" <guest01_at_gmail.com> wrote in message
news:AANLkTikzD7rgXkR+d=HC+Oja6ay7LcOB3iPKZ3UGzXtD_at_mail.gmail.com...
> ok, does not sound good, but I expected something like that, even
> though in theory more CPUs should be able to handle more
> work/authentication processes
>
> We don't really care about caching, we are basically only interested
> in antivirus and category blocking based on username/group (achieved
> with an ICAP server) which does only work with any kind of
> authentication (IP based policy assignment cannot be handled
> properly).
>
> At the moment, we have 30 kerberos helpers responsible for approx 2000
> users (66 users per helper) and not all of them will be used
> extensively.
>
> Maybe there is something wrong in our setup, does any of you have
> experience or even have numbers of how many kerberos authentications a
> recent squid version can handle on todays hardware (let's say multi
> core cpu and lots of RAM) and average user behavior? How big are the
> biggest squid deployments (as forward proxy with authentication)?
>
> btw, I see following messages in my log files, but in my opinion, they
> are NTLM-related.
> --------------------- samba Begin ------------------------
> **Unmatched Entries**
> libads/cldap.c:recv_cldap_netlogon(219) no reply received to cldap
> netlogon : 3771 Time(s)
> libads/ldap_utils.c:ads_do_search_retry_internal(115) ads reopen
> failed after error Referral : 1 Time(s)
> libsmb/clientgen.c:cli_rpc_pipe_close(386) cli_rpc_pipe_close:
> cli_close failed on pipe \NETLOGON, fnum 0x4008 to machine DC1. Error
> was SUCCESS - 0 : 609 Time(s)
> libsmb/clientgen.c:cli_rpc_pipe_close(386) cli_rpc_pipe_close:
> cli_close failed on pipe \NETLOGON, fnum 0x400b to machine dc1.fqdn.
> Error was SUCCESS - 0 : 36 Time(s)
> libsmb/clientgen.c:cli_rpc_pipe_close(386) cli_rpc_pipe_close:
> cli_close failed on pipe \lsarpc, fnum 0x4009 to machine DC1. Error
> was SUCCESS - 0 : 609 Time(s)
> libsmb/credentials.c:creds_client_check(324) creds_client_check:
> credentials check failed. : 3923 Time(s)
> nsswitch/winbindd_group.c:winbindd_getgrnam(519) group prod360 in
> domain OUR_DOMAIN_HERE does not exist : 27 Time(s)
> rpc_client/cli_netlogon.c:rpccli_netlogon_sam_network_logon(1030)
> rpccli_netlogon_sam_network_logon: credentials chain check failed :
> 3923 Time(s)
> ---------------------- samba End -------------------------
>
>
>
> On Wed, Feb 16, 2011 at 10:32 PM, Amos Jeffries <squid3_at_treenet.co.nz>
> wrote:
>> On Wed, 16 Feb 2011 13:28:29 +0100, guest01 wrote:
>>>
>>> Hi,
>>>
>>> We had to bypass the kerberos authentication for now (most of the
>>> users will be authenticated by IP (there are already more than 10000
>>> unique IPs in my Squid logs). iirc, disabling the replay cache did not
>>> help much. There is a load avg of 0.4 right now (authenticating about
>>> 9000 users per IP and 1000 with Kerberos) with approx 450 RPS (2
>>> strong servers), which looks pretty good.
>>>
>>> What do you think? Can SMP functionality of Squid 3.2 reduce our load
>>> problem significantly? At the moment, we have multiple independent
>>> squid processes per server (4 squid instances, 16 cpus), but I don't
>>> see any way (except adding more hardware) to authenticate >10000 with
>>> Kerberos.
>>
>> SMP will help with the management of those 4 instances on each machine,
>> dropping it to one config file they all work from and one SNMP contact
>> port
>> one cachemgr contact port etc.
>> But I think total load, helper process count and cache duplication
>> problems
>> will remain unchanged with the current SMP capabilities.
>>
>> Amos
>>
>>
>
Received on Fri Feb 18 2011 - 08:15:31 MST