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 [email protected] _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
