Interesting results for getservbyname() performance (and possible changes for /etc/services)

[Phil Knirsch]

Hi folks.

As i'm now the proud owner of setup i'm planing on doing a major update 
to /etc/services which has been fairly constant for the past few years 
with only minor updates.

I have downloaded the official IANA list for all registred services and 
ran a few tests using getservbyname(). The new file is about 20x as big 
as the old one (580 lines <-> 13604 lines).

All searches are repeated 10000 times with this simple app:

#include <netdb.h>

main(int argc, char *argv[])
{
         struct servent *sv;
         int i;

         for (i=0; i< 10000; i++)
                 sv = getservbyname(argv[1], NULL);
}

Here the results:

Unkown service "foobar":
   old: 7.65user 5.51system 2:06.60elapsed
   new: 63.99user 10.55system 3:09.55elapsed

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

Known service "ssh" (very early in both files):
   old: 0.20user 0.27system 0:00.47elapsed
   new: 0.26user 0.28system 0:00.55elapsed


All tests were run on a very current FC-Devel machine (updated 
yesterday) with a standard NIS/Kerberos configuration.

So, what this tells me is that for the unknow service case both are not 
equally bad but not drastically different.

For services in the middle the difference is what i would have expected 
for uncached linear reads and parsing, roughly 1:20.

For very early services though the difference is really neglectable.

Now, i know and understand how and why glibc does the getservbyname() 
call as it does (namely, every time opening, reading and parsing the 
file). It neither caches calls nor does any other fancy stuff (how could 
it? The order in the file is arbitrary, so the only possibility is to do 
a linear read and parse of the file).

 From what i see though is that, if we use "our" old /etc/services file 
and just extend it with newer and/or updated services we can only win: 
Found services will even for the huge new file always be faster than 
none found ones, and usually an application should search for an 
existing service. With our old file though i'd suspect that some apps 
might hit the unkown service fairly often, which are very likely to be 
in the complete official IANA list and therefore would be speed up with 
the extension.

Another thing that might be worth looking into is to run some analysis 
what services are most often requested on standard everyday machines and 
maybe move them more to the front so they get read and parsed earlier.

Comments and suggestions are of course always welcome.

Oh, and this is not a change i'm planing on doing for FC5, for that it's 
wayyy to late, so this is all FC6 material.

Read ya, Phil

-- 
Philipp Knirsch      | Tel.:  +49-711-96437-470
Development          | Fax.:  +49-711-96437-111
Red Hat GmbH         | Email: Phil Knirsch <phil at 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.