[nsd-users] NSD zonec performance patches
martin.svec at zoner.cz
Wed Mar 31 15:43:05 UTC 2010
thank you for accepting the patches. In these days we finalize a
migration of our nameservers from Bind9 to NSD. There are still some
problems with NSD for domain service providers like us, but Bind9 has
its own problems too -- and I really like the clean and simple design of
NSD :-). I send our remarks and suggestions to the list as soon as our
nameservers will be successfully switched to NSD. (And maybe more
patches, I have at least two now -- one that disables xfrd daemon and
the other that aggregates bind8 stats over all server processes.)
Matthijs Mekking napsal(a):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Hi Martin,
> I have looked at your patches and they look good. Here is what I did
> with them:
> - - I have applied the b64_pton patch without modification.
> - - I have made the mmap patch configurable. You can enable it at build
> time, with --enable-mmap. I have marked it experimental. By default off.
> - - I have applied the parse-token-leaks patch the way it is.
> - - I did not do the adaptive-rrtype-lookup patch. It changes lookup
> behavior in favor of frequently used rrtypes. However, it's not clear to
> me if this benefit the future lookups in all cases. In some cases it
> might perform worse (for example zones sorted on rrtype).
> The applied patches are now in trunk. Before releasing, they will
> undergo another round of reviewing.
> Thank you very much for your effort!
> Best regards,
> Martin Svec wrote:
>> Hi Matthijs, Paul,
>> I send you two more patches that slightly improve zonec performance.
>> (a) parse-token-leaks.patch -- avoids unused calls of region_strdup and
>> zoctet in parse_token. I believe it also fixes a memory leak in zonec.
>> (b) adaptive-rrtype-lookup.patch -- tries to improve O(n) complexity of
>> rrtype_destriptor_by_name(). Because I didn't want to rewrite
>> rrtype_descriptors table from scratch, I added another table containing
>> pointers to named rrtype_descriptors. In this table, frequently used rr
>> types are automatically moved forward, which reduces the overall number
>> of strcasecmp comparisons.
>> The patches are public domain, without any guarantees ;-) They improve
>> compilation time by few percents, depending on the contents of zone files.
>> Unfortunately, I see no more room for (micro)optimizations in zonec.
>> With all my patches, the profile looks as follows:
>> 32.96% zonec /usr/sbin/zonec [.] yylex
>> 9.19% zonec /usr/sbin/zonec [.] yyparse
>> 6.35% zonec /usr/sbin/zonec [.] label_compare
>> 4.76% zonec /usr/sbin/zonec [.] write_data_crc
>> 3.55% zonec /usr/sbin/zonec [.] b64_pton
>> 3.47% zonec /usr/sbin/zonec [.] parse_token
>> 3.24% zonec /lib64/libc-2.10.1.so [.] memcpy
>> 2.49% zonec /usr/sbin/zonec [.] dname_compare
>> 2.33% zonec /lib64/libc-2.10.1.so [.] __strcasecmp
>> 1.98% zonec /lib64/libc-2.10.1.so [.] _IO_file_xsputn
>> 1.86% zonec /lib64/libc-2.10.1.so [.] _IO_fwrite
>> Yylex seems to be a great candidate for optimization, but most of its
>> time is spent in the innermost loop generated by lex. The same holds for
>> yyparse. And the other functions are below 6%...
>> Best regards
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
More information about the nsd-users