Should we make it a default option? It seems like in most cases it helps a lot. ----------------------------------------------------------------------------------------------
--- Comment #41 from Bojan Smojver bojan@rexursive.com 2012-03-18 00:50:01 EDT --- (In reply to comment #38)
One thing you might try is setting 'ldap_referrals = false'.
Bingo! 1.6 secs with cache blown away, 0.16 secs with cache. Only about two orders of magnitude faster. :-)
Thank you. Much appreciated!
On Sun, Mar 18, 2012 at 12:54:35PM -0400, Dmitri Pal wrote:
Should we make it a default option? It seems like in most cases it helps a lot.
Changing the default might help performance but it might also cause the SSSD to not return valid data..and historically we've been preferring correct over fast.
Perhaps we should only document the proc and cons better?
On Sun, 2012-03-18 at 21:31 +0100, Jakub Hrozek wrote:
On Sun, Mar 18, 2012 at 12:54:35PM -0400, Dmitri Pal wrote:
Should we make it a default option? It seems like in most cases it helps a lot.
Not really in "most cases". It helps a lot in Active Directory environments because AD is pathological about referrals. It always forces three referrals at every non-base search lookup, regardless of whether such referrals would accomplish anything. This means that for each level of nested groups, we end up with three useless searches that take a lot of wallclock time).
Changing the default might help performance but it might also cause the SSSD to not return valid data..and historically we've been preferring correct over fast.
Perhaps we should only document the proc and cons better?
I agree with Jakub. In some environments, failing to support referrals can lead to missing data. I don't think we want that to be the default, even for a sizeable performance gain. Furthermore, since defaulting to having it on has been the case for quite a while now, changing the default would negatively impact those environments that are relying on it.
So I think we need to leave it enabled by default. Probably we really need to document this better in the manpage and also add an entry to the SSSD FAQ on the wiki.
On Mon, Mar 19, 2012 at 07:26:22AM -0400, Stephen Gallagher wrote:
On Sun, 2012-03-18 at 21:31 +0100, Jakub Hrozek wrote:
On Sun, Mar 18, 2012 at 12:54:35PM -0400, Dmitri Pal wrote:
Should we make it a default option? It seems like in most cases it helps a lot.
Not really in "most cases". It helps a lot in Active Directory environments because AD is pathological about referrals. It always forces three referrals at every non-base search lookup, regardless of whether such referrals would accomplish anything. This means that for each level of nested groups, we end up with three useless searches that take a lot of wallclock time).
Changing the default might help performance but it might also cause the SSSD to not return valid data..and historically we've been preferring correct over fast.
Perhaps we should only document the proc and cons better?
I agree with Jakub. In some environments, failing to support referrals can lead to missing data. I don't think we want that to be the default, even for a sizeable performance gain. Furthermore, since defaulting to having it on has been the case for quite a while now, changing the default would negatively impact those environments that are relying on it.
So I think we need to leave it enabled by default. Probably we really need to document this better in the manpage and also add an entry to the SSSD FAQ on the wiki.
I agree.
sssd-devel@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Stephen Gallagher