Hi again,
Stephen Gallagher wrote:
This has been discussed before, but we're not currently planning
on
implementing it. There are several reasons for this:
1. Modern SSSD implementations actually have two caches, one in shared
memory and another provided by the NSS responder. So we would somehow
need to maintain both of them in this option.
2. It would be an unnecessary performance hit to do a write() for every
read() of the cache.
The best we can realistically do here I think would be to provide a log
of cache-misses. So only on those cases where we actually go out to the
ID provider to refresh the cache should be logged and stored. I'm not
really sure what value this information provides though.
I was just looking for something to get a feeling of
the efficiency of the caching. I was not thinking about
writing stuff to logfiles (that would mean too much IO),
more like keeping the statistics in memory and a tool
that contacts the daemon, gets the stuff and prints it
to stdout.
Anyway, it is not THAT important, we already collect information
about how many queries each LDAP client sends, so we see the
end result. In case of "nscd" it is always a good idea to have
a look if it still works, I guess (and hope) SSSD is much more
stable.
Olaf
--
Olaf Gellert email gellert(a)dkrz.de
Deutsches Klimarechenzentrum GmbH phone +49 (0)40 460094 214
Bundesstrasse 45a fax +49 (0)40 460094 270
D-20146 Hamburg, Germany www
http://www.dkrz.de
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Prof. Dr. Thomas Ludwig
Registergericht: Amtsgericht Hamburg, HRB 39784