Generic reasons for recursive performance not to peg CPU?

Leonard Mills lenm at yahoo.com
Mon Jan 13 02:07:36 UTC 2014


Are you allowing long answers when authoritative?  Performance measurements with and without additional data in responses is measurable (imo around 12% more network traffic from the replies on auth-only servers).

hth,
Len





On Sunday, January 12, 2014 5:54 PM, Doug Barton <dougb at dougbarton.us> wrote:
 
Thanks for the response, but that's not it. The auth-only responses are 
>generating a lot more traffic than the recursive.
>
>Doug
>
>
>
>On 01/12/2014 05:21 PM, Sten Carlsen wrote:
>> Wild guess: network bandwidth runs out before CPU? Why the difference, I
>> have no clue.
>>
>> On 13/01/14 02.16, Doug Barton wrote:
>>> Howdy,
>>>
>>> Without going into too much detail, doing some performance testing and
>>> am seeing a weird result. On the same systems authoritative queries
>>> will happily peg the CPU. However when running recursive queries (with
>>> a small zone, all data cached before testing) the CPU never gets above
>>> 80%. The disk is nearly inactive on both systems, and there is no
>>> swapping. Using BIND 9.9.4.
>>>
>>> Is there perhaps something obvious I'm overlooking here? Any
>>> suggestions are welcome.
>
>_______________________________________________
>Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
>bind-users mailing list
>bind-users at lists.isc.org
>https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140112/b04faeb0/attachment.html>


More information about the bind-users mailing list