Fields changed

coverity: =>
description: https://bugzilla.redhat.com/show_bug.cgi?id=750373

{{{
+++ This bug was initially created as a clone of Bug #750359 +++

Description of problem:
When the new feature of user and group name aliases was added, it introduced a
serious performance regression. The cause of this was that our cache lookups
added an additional search parameter, but we did not add a new index for this
attribute. As a result, the cache lookup is forced to look at all entries in
the database.

The fix for this is very simple and straightforward: we just need to add an
index on this new attribute.

Version-Release number of selected component (if applicable):

How reproducible:
Consistent, but tricky.

Steps to Reproduce:
1. Create an LDAP account with a lot of users > 3000
2. Request all of these users once so that they are cached. (Such as with a
looping script)
3. Disable access to the LDAP server (shut it down, etc.)
4. Re-request all of the users, timing it with the 'time' command.

Actual results:
This will take minutes.

Expected results:
Should take < 10 seconds.

Additional info:

This was reported by a user who was testing with our latest upstream release.
They saw a significant performance hit in their environment. Specifically, they
start an apache instance with ~3500 virtual hosts each related to a separate
LDAP user. In 6.1, this took about five minutes to start. With 6.2, it took 20
minutes. This is an unacceptable degradation.

(For the record, when I provided them with a patch to test, they verified that
it reduced their startup time to approximately six seconds, due to this fix
as well as other performance enhancements in the 6.2 codebase).

--- Additional comment from pm-rhel@redhat.com on 2011-10-31 15:43:41 EDT ---

This request has been proposed as a blocker, but a release flag has
not been requested. Please set a release flag to ? to ensure we may
track this bug against the appropriate upcoming release, and reset
the blocker flag to ?.

--- Additional comment from syeghiay@redhat.com on 2011-10-31 16:00:48 EDT ---

Approved blocker for Snapshot 5.
Please respin advisory build by Nov 2 noon Eastern.

--- Additional comment from errata-xmlrpc@redhat.com on 2011-10-31 16:44:57 EDT

Bug report changed to ON_QA status by Errata System.
A QE request has been submitted for advisory RHEA-2011:11617-01
http://errata.devel.redhat.com/errata/show/11617

--- Additional comment from errata-xmlrpc@redhat.com on 2011-10-31 16:44:58 EDT

Bug report changed to ON_QA status by Errata System.
A QE request has been submitted for advisory RHEA-2011:11617-01
http://errata.devel.redhat.com/errata/show/11617
}}}
=> https://bugzilla.redhat.com/show_bug.cgi?id=750373

{{{
+++ This bug was initially created as a clone of Bug #750359 +++

Description of problem:
When the new feature of user and group name aliases was added, it introduced a
serious performance regression. The cause of this was that our cache lookups
added an additional search parameter, but we did not add a new index for this
attribute. As a result, the cache lookup is forced to look at all entries in
the database.

The fix for this is very simple and straightforward: we just need to add an
index on this new attribute.

Version-Release number of selected component (if applicable):

How reproducible:
Consistent, but tricky.

Steps to Reproduce:
1. Create an LDAP account with a lot of users > 3000
2. Request all of these users once so that they are cached. (Such as with a
looping script)
3. Disable access to the LDAP server (shut it down, etc.)
4. Re-request all of the users, timing it with the 'time' command.

Actual results:
This will take minutes.

Expected results:
Should take < 10 seconds.

Additional info:

This was reported by a user who was testing with our latest upstream release.
They saw a significant performance hit in their environment. Specifically, they
start an apache instance with ~3500 virtual hosts each related to a separate
LDAP user. In 6.1, this took about five minutes to start. With 6.2, it took 20
minutes. This is an unacceptable degradation.

(For the record, when I provided them with a patch to test, they verified that
it reduced their startup time to approximately six seconds, due to this fix
as well as other performance enhancements in the 6.2 codebase).

--- Additional comment from pm-rhel@redhat.com on 2011-10-31 15:43:41 EDT ---

This request has been proposed as a blocker, but a release flag has
not been requested. Please set a release flag to ? to ensure we may
track this bug against the appropriate upcoming release, and reset
the blocker flag to ?.

--- Additional comment from syeghiay@redhat.com on 2011-10-31 16:00:48 EDT ---

Approved blocker for Snapshot 5.
Please respin advisory build by Nov 2 noon Eastern.

--- Additional comment from errata-xmlrpc@redhat.com on 2011-10-31 16:44:57 EDT

Bug report changed to ON_QA status by Errata System.
A QE request has been submitted for advisory RHEA-2011:11617-01
http://errata.devel.redhat.com/errata/show/11617

--- Additional comment from errata-xmlrpc@redhat.com on 2011-10-31 16:44:58 EDT

Bug report changed to ON_QA status by Errata System.
A QE request has been submitted for advisory RHEA-2011:11617-01
http://errata.devel.redhat.com/errata/show/11617
}}}

milestone: NEEDS_TRIAGE => SSSD 1.5.15
owner: somebody => sgallagh
patch: => 1
rhbz: =>
tests: => 0
testsupdated: => 0
upgrade: => 0

Fixed by:
- 0387564f38698c5301b76b24eda000c448174171 (master)
- 332ac6dd0b1c475e8e810ff10c222f52ffa35fcf (sssd-1-6)
- 5bcfca845cc1e7a47a74ab1f912534d4e877ecdb (sssd-1-5)

resolution: => fixed
status: new => closed

Fields changed

rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=750373 750373]

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2119

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.