another performance tuning question

[Mike Hoskins (michoski)]

-----Original Message-----

From: "Jeremy C. Reed" <jreed at isc.org>
Date: Friday, November 30, 2012 4:18 PM
To: "Adamiec, Lawrence" <ladamiec at kentlaw.iit.edu>
Cc: "bind-users at lists.isc.org" <bind-users at lists.isc.org>
Subject: Re: another performance tuning question

>On Fri, 30 Nov 2012, Adamiec, Lawrence wrote:
>
>> I got similar results when running against the master server.
>
>Then why so many lost?
>
>>   Queries sent:         11000 queries
>>   Queries completed:    8968 queries
>>   Queries lost:         2032 queries
>...
>>   Percentage completed:  81.53%
>>   Percentage lost:       18.47%
>
>Look at your queryperf data file and figure out what is not hosted by
>you.  Some of my systems get around 60,000 QPS with none lost.  If
>really do host these on same system, and are really lost, then will need
>other research.
>
>Even if you are doing recursive work, your results are quite slow. you
>may want to look in your queryperf input to see what is causing
>problems. (It may not be a realistic, real world input set.)

Based on your "hosted by you" reference, I assume 60K QPS was only
resolving local names?  If not I'd love to see the config.

Some extra data points for the OP:

I might have misread (or be mis-remembering since I last tested), but I
think the default resperf query file includes ten million "real-world"
entries -- if testing recursion, try it vs generating your own.

If you are not just doing local queries, from experience server hardware
(physical or virtual) and bandwidth play a big part in the numbers.  More
cores = more worker threads, faster connectivity to upstream servers =
more responses.

With the default resperf query file and drop rate capped at 1%, I was able
to get ~20K qps w/ four vCPUs vs ~5K with one vCPU (VMware, RHEL, BIND
9.8).