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

[Robert Edmonds]

W.C.A. Wijngaards wrote:
> On 01/06/2014 07:46 PM, Robert Edmonds wrote:
> > W.C.A. Wijngaards wrote:
> >> 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).
> > 
> > OK, that makes sense.
> > 
> >> 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
> > 
> > Yes, the problem is not that the localzone lookup occurs first, per
> > se, but that the localzone lookup causes measurable contention with
> > other threads.
> 
> The lock is changed to a rwlock, so that the threads can all acquire
> the readlock to answer queries.  That should reduce contention?  The
> call order is not changed.

Hi, Wouter:

I benchmarked svn r3047 (spinlock?) against svn r3048 (rwlock) and the
difference is not as dramatic.  Maybe 0.5% - 1% speedup.  It doesn't
appear to harm performance at any level, but it's also not as dramatic
as eliding the localzone lookup (~10%).

-- 
Robert Edmonds
edmonds at debian.org