IdP use of LDAP and connection pooling
fox at washington.edu
Thu Sep 8 20:02:31 BST 2011
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.
The only time I occasionally see a failure is on a test idp that gets
accessed once every few days. It sometimes fails to return any
attributes. Retry works as normal.
On Thu, 8 Sep 2011, Cantor, Scott wrote:
> Date: Thu, 8 Sep 2011 11:26:12 -0700
> From: "Cantor, Scott" <cantor.2 at osu.edu>
> To: "users at shibboleth.net" <users at shibboleth.net>
> Reply-To: Shib Users <users at shibboleth.net>
> Subject: IdP use of LDAP and connection pooling
> Is there any conventional wisdom or experience with the use of connection
> pooling in the IdP data connectors for LDAP, and specifically AD?
> We're expanding use of LDAP as a data source, but my expertise lies
> heavily on the RDBMS side and how the pooling behaves there. I did some
> initial playing around adding a connection pool and am seeing what I kind
> of expected, which is constant LDAP connection resets when the pools
> validate when connections are idle.
> I'm just wondering these kinds of things:
> - are pools necessary to get reasonable performance on highly loaded IdPs?
> - do they handle failed connections reasonably without ever surfacing them
> as actual data connector failures?
> - are there ways to maintain connections and avoid the timeouts from the
> client end?
> - is pool validation even needed, or does it just retry on failures and
> handle things gracefully?
> I use LDAP as a secondary source right now, with no pooling yet, and it's
> basically fine, though I don't know the actual load on the AD servers.
> Last thing I want is to add pooling and have it cause failures (which
> poorly implemented RDBMS pools do cause).
> -- Scott
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users