#843 Login time increases strongly if more than one domain is configured
Closed: Fixed 7 years ago Opened 13 years ago by sbose.

If there are multiple domains configured, e.g. 'domains=d1,d2,d3', the time until a user form domain d3 is logged in increases (2-3 times) compared to a configuration with only one domain 'domains=d3'.


Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.7.0
patch: => 0

Pushing out as multiple domain is not a popular use case yet.

milestone: SSSD 1.8.0 => SSSD 1.9.0

(In #1126) There are a number of improvements we should work on while fixing this. In particular, we should seek to resolve the performance issue identified in bug #843.

The current approach behaves as follows (I will use {{{getpwnam()}}} as the representative function, though all are equivalent).

The NSS responder will check the cache for the first domain in the list. If it is empty or expired, the Responder will query the Data Provider. If the Data Provider returns DP_ERR_OK, the cache is checked again. If the entry is still not present, it advances to the next domain. This pattern repeats.

The problem with this approach is that it means that for a configuration of N domains, if a user is found in the last domain in the list, SSSD will go to the server N-1 times before ever checking the cache of the correct domain.

The proposed new approach is for us to search each domain's cache first. If any domain has the requested, non-expired entry, it should be returned immediately. If all domains lack the entry, only then should we begin to iterate through them. For NSS lookups, we should NOT limit ourselves only to the domain with an expired entry for the user, because we need to be able to catch new users being added to earlier domains. So in the complete cache-miss case, we will still iterate through all domains, but a cache-hit will not result in network activity.

For PAM, we will take an additional shortcut. Since it is reasonable to assume that the login program will have made a {{{getpwnam()}}} call prior to starting the PAM conversation, we will limit our mandatory {{{initgroups()}}} lookup to only domains with an expired entry (if one exists, otherwise we will try them in series).

blockedby: => 1126

Fields changed

blockedby: =>
blocking: =>
milestone: SSSD 1.9.0 => SSSD Infopipe
rhbz: =>

Fields changed

owner: somebody => nalin

Fields changed

rhbz: => 0

Fields changed

feature_milestone: =>

Fields changed

milestone: SSSD Infopipe Feature => NEEDS_TRIAGE

We also need to look into how the new responders such as sudo, ssh and autofs implement the loop and convert them into using the same logic as services use.

Fields changed

component: PAM => NSS
milestone: NEEDS_TRIAGE => SSSD 1.9.0
owner: nalin => sgallagh

Fields changed

milestone: SSSD 1.9.0 => SSSD 1.11.0 (LTM)
type: enhancement => defect

Fields changed

proposed_priority: => Nice to have

Fields changed

blockedby: => 1126

Moving all the features planned for 1.10 release into 1.10 beta.

milestone: SSSD 1.11.0 (LTM) => SSSD 1.10 beta

Fields changed

priority: major => minor

Fields changed

selected: => Not need

Moving tickets that are not a priority for SSSD 1.10 into the next release.

milestone: SSSD 1.10 beta => SSSD 1.11 beta

Putting up to NEEDS_TRIAGE so we can discuss the priority on the next meeting.

changelog: =>
design: =>
design_review: => 0
fedora_test_page: =>
keywords: => localaccounts
review: => 0

Fields changed

milestone: SSSD 1.13 beta => NEEDS_TRIAGE

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13 beta

Fields changed

mark: => 0

Required for local account support.

milestone: SSSD 1.13 beta => SSSD 1.13 backlog

Fields changed

milestone: SSSD 1.13 backlog => SSSD 1.14 beta
priority: minor => major

Fields changed

priority: major => critical
sensitive: => 0

Pavel already started submitting patches that use the new cache_req code but until we switch the responders to the new code, we can't make this switch either, sorry.

Therefore, I'm moving this ticket out of the 1.14 bucket for capacity reasons.

milestone: SSSD 1.14 beta => SSSD 1.15 beta

This would be solved together with using shortname for trusted domains, so Fabiano is probably the right owner for both.

milestone: SSSD Future releases (no date set yet) => SSSD 1.15.2
owner: sgallagh => fidencio

Metadata Update from @sbose:
- Issue assigned to fidencio
- Issue marked as blocked by: #2228
- Issue marked as depending on: #1126
- Issue set to the milestone: SSSD 1.15.2

7 years ago

This issue was fixed in the following commits:
* 606015a
* 8bb6680
* 9286d0d
* 7cd2264
* 828fe75

This issue was fixed in the following commits:
* 606015a
* 8bb6680
* 9286d0d
* 7cd2264
* 828fe75

but I can't close the ticket because of the blocks/depends on which is a pagure bug..

but I can't close the ticket because of the blocks/depends on which is a pagure bug..

Metadata Update from @jhrozek:
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch reset (from 0)
- Custom field review reset (from 0)
- Custom field sensitive reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue unmarked as depending on: #2228

7 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

7 years ago

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/1885

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.

Login to comment on this ticket.

Metadata