Maintained by: NLnet Labs

[Unbound-users] ~10% performance increase in worker_handle_request()

W.C.A. Wijngaards
Mon Jan 6 17:18:07 CET 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Robert,

On 12/29/2013 08:41 PM, Robert Edmonds wrote:
> Making the local_zone lookup occur after the cache lookup has
> little effect under low load, but improves performance by ~10%
> under high load. This has the side effect of making runtime updates
> to the local_zone data non-instantaneous if there is a conflicting
> entry in the cache, because the cache would be consulted first.
> This side effect might be fixable by having updates to the
> local_zone database do an implicit flush, which adds some
> additional complexity, but it's probably worth doing for up to a
> ~10% performance benefit under certain loads.

Very interesting, some optimizations can be made by making the local
zone lookup better (and its locking).

However, moving the check after the cache check is not a good idea.
The localzone and localdata statements are supposed to be able to
override the DNS contents from the internet.  Checking it earlier
means that this always happens.  Messing with cache flushes sounds
very bad, a query may create a recursive query that would then
override the configuration and so on, lots of complexity as well as
worries about giving the 'wrong' answers (as compared to the
configuration).

It would be better to optimise the localzone lookup itself somehow.
Not sure what the best way is, it is visible that it uses a rbtree now
and that this is slower than the hashtable that the other cache employs

Best regards,
   Wouter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSytc+AAoJEJ9vHC1+BF+NhFEQAJM62IS64zMGK6F31RjoLpyz
BUlNSZtT3gOPfGJGlZZOtg93aN6FnlLUMx6N3Vyml9qPKa2OCd/A0ekbwA7E0q3d
+0x6X0ioxWPOdOiutQ83j8wBnlmQA35RxSGy96zFHIHE1ofB/NA2jJae4UlHjUFd
pbXwI2GiOfiRoC5LX86nSw2oQps2fgnU0gwcTcqAaBgBOzdgAclVnJ7EYz3l6xdQ
eYOcGDH7XSD7HEflPp/5JyBUXHxW5apTJQlti5Qg47i+9yussi/rTyF1T4dVxhwJ
fY7rSWf+HsWF+aVCnGRTdExjrCTjmKnaDNSzLWB6FNHhFmnv8JabPxpHwpBn8miS
MfkLRGLikIFG6T2+FHWAdrsAAmd3w+SdsPX/JQ3nn9rC8uAl1zpc/yaM00xV8IYr
lL/GTF1MxXs4ndDORafXx97Gg8jch52bCZzVS0y5JkMycWKQUJTRIbaDWnZ2AiEs
wXDYLSbyK1BWbi/e3/k/KplFlVX4THUm7dsS77MADUKEYBdtEUun2qNFo4wxO1Nj
IyyIaaWx2/ApN/C5o13JJhPt1mBeeiaX5dq/utnEdikABhVPPM2bjwvpE8OgvNil
MmtvoGGPSp/9HUlNGRMJWnR+zXtxKDYoEEWokFhUgAhPXd6URE9AoUdIcdElTZ7W
KmayJVbcrWFRraJM5cwF
=/U9B
-----END PGP SIGNATURE-----