We're struggeling with the performance of IPA, and have tried switching
to the ldap backend for sssd to be able to see what's happening. The
attached trace is from a RHEL6.4 client running "id janfrode" with the
following sssd backend:

id_provider = ldap
auth_provider = ldap
ldap_schema = rfc2307bis
ldap_uri = ldap://ipa2.example.net, ldap://ipa1.example.net
ldap_search_base = dc=example,dc=net
ldap_user_search_base = cn=users,cn=accounts,dc=example,dc=net
ldap_group_search_base = cn=groups,cn=accounts,dc=example,dc=net
ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=net
ldap_tls_cacert = /etc/ipa/ca.crt
ldap_tls_reqcert = never
cache_credentials = True
enumerate = false
debug_level = 1
krb5_server = ipa1.example.net

Please ignore the timings in the trace, as the ldap-server had too high
debug level when it was collected.

What we find very strange in the trace is:

        - how many ldap searches are done (144!)
        - that nesting is handled by the client, instead of using
        - that all group members are searched individually, and multiple
          times if they're members of multiple groups

Ldap-searches are probably (without this high debug level) taking
0.02-0.03s, so 144 of these is causing us 3-4s to resolve all my groups.

I can get the time "id janfrode" takes down to less than 1s if I use
ldap_schema=rfc2307, turn of nesting and use the cn=compat tree for
group lookups... but ideally I'd want to use the ipa-backend so that we
can use the IPA HBAC stuff..


Attachment: trace.bz2
Description: BZip2 compressed data

Freeipa-users mailing list

Reply via email to