<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 1, 2016 at 4:04 PM, IAM David Bantz <span dir="ltr"><<a href="mailto:dabantz@alaska.edu" target="_blank">dabantz@alaska.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div> - I understand there's delay entailed between in waiting for a failed attempt to authN at one directory before attempting another, but that seems to be << 1 sec; is there some further cascading effect or different sort of performance hit to be concerned about?</div></div></div></blockquote><div><br></div><div>I don't think so. Opening new connections is the most expensive activity. Assuming your directory is properly indexed, pooling connections is where you're going to get the most benefit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>- I've configured several steps of fail-over (in the v2 attribute-resolver data connectors as well as login.config for authN). Are you saying that with similar levels of redundancy using v3 aggregate resolver I may be establishing concurrent connections with 3 - 5 LDAP directories? Wouldn't THAT entail a performance hit of some sort?</div></div></div></blockquote><div><br></div><div>Only on IDP startup. Assuming your pools are tuned to keep connections alive, the work required to keep pools healthy is minimal compared to opening and closing connections.</div><div><br></div><div>--Daniel Fisher</div><div><br></div></div></div></div>