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.