[nsd-users] NSD zonec performance patches

[Martin Svec]

Hi Matthijs,

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.)

Best regards
Martin

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,
>
> Matthijs
>
> 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
>> Martin
>>
>>
>>     
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQEcBAEBAgAGBQJLs1ZhAAoJEA8yVCPsQCW5/5gH/0Oa8kUgIk7C+c7pA29c6r6o
> 5zkChsyX83dVwfnPhtvvOdbbk1rG/RRuiTBYtMRnmyrPZmueXJ/O+8rIO/MdLv1n
> YeHXQaus7aPdb58c9r+rZy0tpbFqow2V1Zj03io7RdFsDIYCfUFnh1E2ap9DUF1/
> zMOD2+S/KvhIJASTg20+2YMBzVfqhA3TGj/VnG5MFqbab0/cUnfXLz8CMyM3WNF2
> HsvTfub3DWvtUzpBAy8md6v+xnNIz4JSdxl80rht0NhSzx4HbTk491/9JhUem46c
> Wf3YX/4WUduAtoVSDGFB2ZKV+Z6xgZoZXnmUDwnCuRYpVEEnsP5/zDWsuraljqA=
> =G56M
> -----END PGP SIGNATURE-----
>