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.04elapsed
The 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@xxxxxxxxx>
Hauptstaetterstr. 58 | Web: http://www.redhat.de/
D-70178 Stuttgart
Kaa's Law: In any sufficiently large group of people most are idiots.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list