[SSSD] No negative cache with sssd_nss

Stephen Gallagher sgallagh at redhat.com
Tue Jun 26 15:43:32 UTC 2012


On Tue, 2012-06-26 at 16:28 +0200, Jan Engelhardt wrote:
> Hi,
> 
> 
> it seems that sssd does not cache negative responses from the shadow/NSS 
> backend. This is particularly observable when repeatedly querying for 
> groups that do not exist in /etc/group, but do exist in LDAP. sssd is 
> configured to search local db, plus another server's LDAP tree.
> 
> If the group "clients" is in LDAP, the following testcase below runs in 
> about ~8.5 sec on the reference machine. However, if I add the "clients" 
> group to the end of /etc/group, it completes in like 1.3 sec.
> 
> When only in LDAP, tcpdump shows no activity on port 389, so at least 
> the positive caching does work. However, the negative response from NSS 
> increases the execution time significantly, which leads me to believe 
> that part is not cached.
> 
> ---8<---
> #include <stdio.h>
> #include <stdlib.h>
> #include <pwd.h>
> #include <grp.h>
> 
> int main(void)
> {
>         unsigned int i;
>         struct group *g;
> 
>         for (i = 0; i < 50000; ++i) {
>                 g = getgrnam("clients");
>         }
>         return EXIT_SUCCESS;
> }

Actually, it most certainly is cached locally. If it was going to LDAP
50,000 times, it would take you MUCH longer than 8.5s to get results
back. Naturally, looking up results in a local file is faster than
getting it out of the SSSD's cache database. However, we have sped this
up considerably in SSSD 1.9.0 (currently in beta). We now maintain a
second, in-memory cache for requests that is much faster than
communicating across the socket to the sssd_nss process and then reading
from the database (and processing group nested members).

So if you wanted to test our latest nightlies with this program, I think
you'd find it responding much faster. You'd have one long lag for the
initial LDAP lookup (this time varies depending on network factors), and
then the remaining 49,999 lookups would return in about .001s apiece.

I'd suggest running the test at least twice, since the second run would
be coming exclusively from the cache. You probably want to do this for
your baseline with the current code as well. That way you can rule out
how much of the delay is from the LDAP network lag.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120626/af086aeb/attachment.sig>


More information about the sssd-devel mailing list