Extremely slow IdP login

[Mark Cairney]

We had poor LDAP performance a while ago and the cause turned out to be VT-LDAP derefencing aliases by default in conjunction with our 
MaxRefDepth on the server side being too high. Correcting the MaxRefDepth on the server side fixed the problem and as we didn't use the feature anyway
we added the line: <LDAPProperty name="java.naming.ldap.derefAliases" value="never"/> to the attribute-resolver.xml just to be sure.
This is of course just one solution to one cause of this behaviour.

Ultimately a good look through the Shibboleth and the VT-LDAP documentation and tuning the parameters to tie in as close to your setup as possible is the way to go.

On 2 Aug 2012, at 12:11, Chad La Joie wrote:

> Right, but that doesn't account for anything that I said.
> 
> The reason I'm skeptical that it's the IdP is that we know people who
> run the IdP and do tens of millions of logins a day and don't see a
> problem.  We've also had other deployers have issues like you have and
> it was always something outside the IdP.  For example, in one case,
> there was a load balancer involved in that wasn't allowing the LDAP
> connection to close on the server which eventually exhausted resources
> on the server side.
> 
> You'll simply have to investigate the issue the way you'd investigate
> any slow network service.
> 
> On Thu, Aug 2, 2012 at 7:04 AM, Martin Haase <Martin.Haase at daasi.de> wrote:
>> it was the same host where both the IdP and ldapsearch ran. And just
>> verified an ldapsearch as user tomcat6, and it returns quickly as well.
>> Further ideas?
> 
> -- 
> Chad La Joie
> www.itumi.biz
> trusted identities, delivered
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> 

/****************************

Mark R Cairney
ITI UNIX Section
Information Services

Tel: 0131 650 6565
Email: Mark.Cairney at ed.ac.uk

****************************/


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.