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

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 Thu Feb 17 2011 - 09:42:58 MST