IdP use of LDAP and connection pooling

[Eric Goodman]

On Sep 8, 2011, at 1:10 PM, Daniel Fisher wrote:
> On Thu, Sep 8, 2011 at 3:10 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 9/8/11 3:02 PM, "Jim Fox" <fox at washington.edu> wrote:
> >
> >We use connection pooling for all our accesses to LDAP.  We use TLS, and
> >the overhead of starting up a new session on each query seemed excessive
> >to me.  Our openldap servers keep the sessions open all day.
> 
> Are you using any of the validation options in the pooling element? I see
> the retry count defaults to 1 inside the vt-ldap code, so I'm sure no
> matter what I do, it's just going to drop the failed connection and retry.
> With some cases like that, the problem is if the closed connections hangs
> (very common with database pools) but these don't seem to.
> 
> 
> The most common hangs we've seen and heard about are caused by hardware load balancers that don't send resets to both client and server. I haven't tested the read timeout that Ryan mentioned, but typically setting a timeLimit and doing validation will work around that issue.
> 
> --Daniel Fisher

We had that problem (hardware LB killing connections), and it was pretty ugly. We only use the connection pooling for retrieving attributes, so the behavior we saw was that you'd log in, and if it had been more than an hour (or whatever the LB timeout was) since the previous login, you're SAML assertion to the SP just returned no data. This was with an older version of the IdP (2.1.5, right around when vt-ldap was first added). 

Due to an unrelated PeopleSoft LDAP-handling bug, we ended up lowering the idle timeout on out IdP to on the order of 2 minutes. This effectively made the LB timeout handling a non issue. 

We haven't seen any performance issues with the lower idle timeout window, but we're not a very high volume server (we see 10,000 shib logins on an average day, maybe 30K on a peak day), so I don't know how useful that is as a datapoint.


Eric Goodman
ericg at ucsc.edu



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20110908/7f71e838/attachment.html