Ulrich Drepper wrote:
Ralf Ertzinger wrote:AFAIK nscd can cache everything going through nsswitch.conf, including services.No, you're wrong. nscd only caches passwd, group, hosts data. Nothing else. And I'm reluctant to add support for rarely used other services because the cost doesn't really justify the gains. For this problem, as I told Phil already internally, I think it's perfectly fine to use nss_db. It's really static data so updating the database when a) the /etc/services file changes or b) the nss_db implementation changes, is no big issue.
I've quickly ran some tests with this change. Here the results: Unkown service "foobar": old: 7.65user 5.51system 2:06.60elapsed new: 63.99user 10.55system 3:09.55elapsed old.db: 9.38user 14.36system 2:17.05elapsed new.db: 66.80user 19.56system 3:22.44elapsed Known service "svn" (roughly in the middle of both files): old: 1.92user 0.42system 0:02.35elapsed new: 39.91user 3.52system 0:43.43elapsed old.db: 0.60user 8.30system 0:08.91elapsed new.db: 0.72user 8.48system 0:09.21elapsed Known service "ssh" (very early in both files): old: 0.20user 0.27system 0:00.47elapsed new: 0.26user 0.28system 0:00.55elapsed old.db: 0.68user 8.53system 0:09.22elapsed new.db: 0.62user 8.41system 0:09.04elapsedThe result here is fairly interesting again. For small /etc/services files or if almost always only the first 40-50 services are requested the non-db version wins always. The bigger the file gets though and the more "later" services are requested the faster the db version gets (fairly logical of course).
So the use of the db version depends on wether your applications use a wide range of services and if your /etc/services file is big. As almost always, there is no perfect solution for everyone.
Read ya, Phil
--
Philipp Knirsch | Tel.: +49-711-96437-470
Development | Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch <phil redhat de>
Hauptstaetterstr. 58 | Web: http://www.redhat.de/
D-70178 Stuttgart
Kaa's Law: In any sufficiently large group of people most are idiots.